Wichtige Überlegungen und Einschränkungen Anmeldedaten für Verbundidentitäten

In diesem Artikel werden wichtige Überlegungen, Einschränkungen und Begrenzungen für Anmeldedaten von Verbundidentitäten in Microsoft Entra-Apps und für benutzerseitig zugewiesene verwaltete Identitäten beschrieben.

Weitere Informationen zu den Szenarien, die durch Anmeldedaten für Verbundidentitäten ermöglicht werden, finden Sie unter Übersicht über den Workload-Identitätsverbund.

Allgemeine Überlegungen zu Anmeldedaten für Verbundidentitäten

Gilt für: Anwendungen und benutzerseitig zugewiesene verwaltete Identitäten

Jeder Benutzer mit Berechtigungen zum Erstellen einer App-Registrierung und zum Hinzufügen eines Geheimnisses oder Zertifikats kann einer App Anmeldedaten für eine Verbundidentität hinzufügen. Wenn allerdings im Microsoft Entra Admin Center auf dem Blatt Benutzer>Benutzereinstellungen die Option Benutzer können Anwendungen registrieren auf Nein festgelegt ist, können Sie keine App-Registrierung erstellen und keine Anmeldedaten für eine Verbundidentität konfigurieren. Finden Sie einen Administrator, der die Anmeldedaten für eine Verbundidentität in Ihrem Namen konfigurieren kann, d. h. eine Person mit der Rolle „Anwendungsadministrator“ oder „Anwendungsbesitzer“.

Anmeldedaten von Verbundidentitäten werden nicht auf das Kontingent für Dienstprinzipalobjekte des Microsoft Entra-Mandanten angerechnet.

Einer Anwendung oder einer benutzerseitig zugewiesenen verwalteten Identität können bis zu 20 Anmeldedaten für eine Verbundidentität hinzugefügt werden.

Beim Konfigurieren von Anmeldedaten für eine Verbundidentität müssen mehrere wichtige Informationen angegeben werden:

• Aussteller und Antragsteller sind die wichtigsten Informationen, die zum Einrichten der Vertrauensstellung erforderlich sind. Die Kombination von issuer und subject muss für die App eindeutig sein. Wenn der externe Software-Workload die Microsoft Identity Platform zum Austausch des externen Tokens gegen ein Zugriffstoken auffordert, werden die Werte von Aussteller und Antragsteller der Anmeldedaten für die Verbundidentität anhand der Ansprüche issuer und subject überprüft, die im externen Token bereitgestellt werden. Wenn diese Überprüfung erfolgreich ist, stellt Microsoft Identity Platform ein Zugriffstoken für die externe Software-Workload aus.

• Aussteller ist die URL des externen Identitätsanbieters und muss mit dem Anspruch issuer des ausgetauschten externen Tokens übereinstimmen. Erforderlich. Wenn der issuer-Anspruch führende oder nachfolgende Leerzeichen im Wert enthält, wird der Token-Austausch blockiert. Für dieses Feld gilt eine Zeichenbeschränkung von 600 Zeichen.

• Antragsteller ist der Bezeichner der externen Software-Workload und muss mit dem Anspruch subsubject des ausgetauschten externen Tokens übereinstimmen. Antragsteller hat kein festes Format, da jeder IdP sein eigenes verwendet – manchmal eine GUID, manchmal einen durch Doppelpunkt getrennten Bezeichner, manchmal beliebige Zeichenketten. Für dieses Feld gilt eine Zeichenbeschränkung von 600 Zeichen.

  Wichtig

  Die Werte für die Einstellung Antragsteller müssen exakt mit der Konfiguration in der GitHub-Workflow-Konfiguration übereinstimmen. Andernfalls lehnt Microsoft Identity Platform den Austausch für ein Zugriffstoken ab, nachdem das eingehende externe Token überprüft wurde. Es wird kein Fehler angezeigt, der Austausch schlägt ohne Fehlermeldung fehl.

  Wichtig

  Wenn Sie versehentlich die falschen externen Workload-Informationen in der Einstellung Antragsteller hinzufügen, werden die Anmeldedaten für die Verbundidentität ohne Fehler erfolgreich erstellt. Der Fehler wird erst angezeigt, wenn der Token-Austausch fehlschlägt.

• Zielgruppen listet die Zielgruppen auf, die im externen Token angezeigt werden können. Erforderlich. Sie müssen einen einzelnen Zielgruppenwert hinzufügen, der maximal 600 Zeichen lang sein darf. Der empfohlene Wert lautet „api://AzureADTokenExchange“. Er gibt an, was Microsoft Identity Platform im Anspruch aud im eingehenden Token akzeptieren muss.

• Name ist der eindeutige Bezeichner für die Anmeldedaten für eine Verbundidentität. Erforderlich. Das Feld kann 3–120 Zeichen enthalten und muss URLs akzeptieren können. Alphanumerische Zeichen, Bindestriche und Unterstriche werden unterstützt, aber das erste Zeichen muss alphanumerisch sein.  Nach der Erstellung ist das Feld unveränderlich.

• Beschreibung ist die vom Benutzer bereitgestellte Beschreibung der Anmeldedaten für eine Verbundidentität. Optional. Die Beschreibung wird von Microsoft Entra ID weder überprüft noch validiert. Dieses Feld darf maximal 600 Zeichen enthalten.

Platzhalterzeichen werden in keinem Eigenschaftswert für Anmeldedaten für Verbundidentitäten unterstützt.

Nicht unterstützte Regionen (benutzerseitig zugewiesene verwaltete Identitäten)

Gilt für: Benutzerseitig zugewiesene verwaltete Identitäten

Die Erstellung von Anmeldedaten für Verbundidentitäten wird derzeit für von Benutzern zugewiesene verwaltete Identitäten nicht unterstützt, die in den folgenden Regionen erstellt wurden:

• Asien, Osten
• Israel, Mitte
• Italien, Norden
• Malaysia, Süden
• Mexiko, Mitte
• Katar, Mitte
• Spanien, Mitte

Die Unterstützung für das Erstellen von Anmeldedaten für Verbundidentitäten für von Benutzern zugewiesene Identitäten in diesen Regionen wird schrittweise ausgerollt. Ressourcen in dieser Region, die Anmeldedaten für Verbundidentitäten verwenden müssen, können dies tun, indem sie eine von einem Benutzer zugewiesene verwaltete Identität nutzen, die in einer unterstützten Region erstellt wurde.

Unterstützte Signaturalgorithmen und Aussteller

Gilt für: Anwendungen und benutzerseitig zugewiesene verwaltete Identitäten

Für den Token-Austausch unter Verwendung des Workload-Identitätsverbunds werden nur Aussteller unterstützt, die mit dem RS256-Algorithmus signierte Token bereitstellen. Der Austausch von Token, die mit anderen Algorithmen signiert wurden, funktioniert gegebenenfalls, wurde aber nicht getestet.

Microsoft Entra-Zertifikataussteller werden nicht unterstützt

Gilt für: Anwendungen und benutzerseitig zugewiesene verwaltete Identitäten

Das Erstellen eines Verbunds zwischen zwei Microsoft Entra-Identitäten aus demselben oder verschiedenen Mandanten wird nicht unterstützt. Bei der Erstellung von Anmeldedaten für eine Verbundidentität wird eine Konfiguration des Ausstellers (URL des externen Identitätsanbieters) mit den folgenden Werten nicht unterstützt:

• login.microsoftonline.com
• *.login.windows.net
• *.login.microsoft.com
• *.sts.windows.net

Es ist zwar möglich, Anmeldedaten für Verbundidentitäten mit einem Microsoft Entra-Aussteller zu erstellen, aber der Versuch, diese Anmeldedaten für die Autorisierung zu verwenden, schlagen mit dem Fehler AADSTS700222: AAD-issued tokens may not be used for federated identity flows fehl.

Zeit zur Weitergabe von Änderungen an Anmeldedaten für Verbundidentitäten

Gilt für: Anwendungen und benutzerseitig zugewiesene verwaltete Identitäten

Es dauert eine gewisse Zeit, bis die Anmeldedaten für Verbundidentitäten nach ihrer erstmaligen Konfiguration in der gesamten Region weitergegeben werden. Eine Token-Anforderung, die einige Minuten nach dem Konfigurieren der Anmeldedaten für Verbundidentitäten gesendet wird, kann möglicherweise nicht erfolgreich ausgeführt werden, da der Cache im Verzeichnis mit alten Daten aufgefüllt wird. Während dieses Zeitfensters schlägt eine Autorisierungsanforderung möglicherweise mit der folgenden Fehlermeldung fehl: AADSTS70021: No matching federated identity record found for presented assertion.

Um dieses Problem zu vermeiden, warten Sie nach dem Hinzufügen der Anmeldedaten für eine Verbundidentität eine gewisse Zeit ab, bevor Sie ein Token anfordern. Auf diese Weise wird sichergestellt, dass die Replikation für alle Knoten des Autorisierungsdiensts abgeschlossen wurde. Außerdem wird empfohlen, eine Wiederholungslogik für Token-Anforderungen hinzuzufügen. Wiederholungsversuche sollten für jede Anforderung ausgeführt werden, selbst wenn ein Token erfolgreich abgerufen wurde. Nachdem die Daten vollständig repliziert wurden, sinkt der Prozentsatz an Fehlern.

Keine Unterstützung für parallele Aktualisierungen (benutzerseitig zugewiesene verwaltete Identitäten)

Gilt für: Benutzerseitig zugewiesene verwaltete Identitäten

Die gleichzeitige Erstellung verschiedener Sätze von Anmeldedaten für Verbundidentitäten unter derselben benutzerseitig verwaltete Identität löst eine Logik zur Parallelitätserkennung aus und führt dazu, dass Anforderungen mit dem HTTP-Statuscode 409 aufgrund eines Konflikts fehlschlagen.

In der Version 3.40.0 des Terraform-Anbieters für Azure (Resource Manager) wird ein Update eingeführt, das mehrere Anmeldedaten für Verbundidentitäten nacheinander anstatt gleichzeitig erstellt. Versionen vor 3.40.0 können Fehler in Pipelines verursachen, wenn mehrere Verbundidentitäten erstellt werden. Es wird empfohlen, mindestens die Version 3.40.0 des Terraform-Anbieters für Azure (Resource Manager) zu verwenden, damit mehrere Anmeldedaten für Verbundidentitäten nacheinander erstellt werden.

Wenn Sie Automatisierungs- oder ARM-Vorlagen (Azure Resource Manager) verwenden, um Anmeldedaten für Verbundidentitäten unter derselben übergeordneten Identität zu erstellen, erstellen Sie die Anmeldedaten für Verbundidentitäten nacheinander. Anmeldedaten für Verbundidentitäten, die für verschiedene verwaltete Identitäten gelten, können ohne Einschränkungen parallel erstellt werden.

Wenn Anmeldedaten für Verbundidentitäten in einer Schleife bereitgestellt werden, können Sie sie nacheinander bereitstellen, indem Sie Folgendes festlegen: „mode“: „serial“.

Sie können auch die Eigenschaft dependsOn verwenden, um mehrere neue Anmeldedaten für Verbundidentitäten nacheinander bereitzustellen. Im folgenden Beispiel für eine Azure Resource Manager-Vorlage (ARM-Vorlage) werden nacheinander drei Sätze neuer Anmeldedaten für Verbundidentitäten für eine benutzerseitig zugewiesene verwaltete Identität erstellt, indem die Eigenschaft dependsOn verwendet wird:

{ 
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
    "contentVersion": "1.0.0.0", 
    "parameters": { 
        "userAssignedIdentities_parent_uami_name": { 
            "defaultValue": "parent_uami", 
            "type": "String" 
        } 
    }, 
    "variables": {}, 
    "resources": [ 
        { 
            "type": "Microsoft.ManagedIdentity/userAssignedIdentities", 
            "apiVersion": "2022-01-31-preview", 
            "name": "[parameters('userAssignedIdentities_parent_uami_name')]", 
            "location": "eastus" 
        }, 
        { 
            "type": "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials", 
            "apiVersion": "2022-01-31-preview", 
            "name": "[concat(parameters('userAssignedIdentities_parent_uami_name'), '/fic01')]", 
            "dependsOn": [ 
                "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentities_parent_uami_name'))]" 
            ], 
            "properties": { 
                "issuer": "https://kubernetes-oauth.azure.com", 
                "subject": "fic01", 
                "audiences": [ 
                    "api://AzureADTokenExchange" 
                ] 
            } 
        }, 
        { 
            "type": "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials", 
            "apiVersion": "2022-01-31-preview", 
            "name": "[concat(parameters('userAssignedIdentities_parent_uami_name'), '/fic02')]", 
            "dependsOn": [ 
                "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentities_parent_uami_name'))]", 
                "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials', parameters('userAssignedIdentities_parent_uami_name'), 'fic01')]" 
            ], 
            "properties": { 
                "issuer": "https://kubernetes-oauth.azure.com", 
                "subject": "fic02", 
                "audiences": [ 
                    "api://AzureADTokenExchange" 
                ] 
            } 
        }, 
        { 
            "type": "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials", 
            "apiVersion": "2022-01-31-preview", 
            "name": "[concat(parameters('userAssignedIdentities_parent_uami_name'), '/fic03')]", 
            "dependsOn": [ 
                "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentities_parent_uami_name'))]", 
                "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials', parameters('userAssignedIdentities_parent_uami_name'), 'fic02')]" 
            ], 
            "properties": { 
                "issuer": "https://kubernetes-oauth.azure.com", 
                "subject": "fic03", 
                "audiences": [ 
                    "api://AzureADTokenExchange" 
                ] 
            } 
        } 
    ] 
} 

Azure Policy

Gilt für: Anwendungen und benutzerseitig zugewiesene verwaltete Identitäten

Es ist möglich, über Azure Policy eine Ablehnungsrichtlinie wie im folgenden ARM-Vorlagenbeispiel zu verwenden:

{ 
"policyRule": { 
            "if": { 
                "field": "type", 
                "equals": "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials" 
            }, 
            "then": { 
                "effect": "deny" 
            } 
        } 
}

Drosselungsgrenzen

Gilt für: Benutzerseitig zugewiesene verwaltete Identitäten

Die folgende Tabelle beschreibt die Beschränkungen für Anforderungen an die REST-APIs für benutzerseitig zugewiesene verwaltete Identitäten. Wenn Sie ein Drosselungslimit überschreiten, erhalten Sie einen HTTP 429-Fehler.

Fehler

Gilt für: Anwendungen und benutzerseitig zugewiesene verwaltete Identitäten

Die folgenden Fehlercodes können beim Erstellen, Aktualisieren, Abrufen, Auflisten oder Löschen von Anmeldedaten für Verbundidentitäten zurückgegeben werden.