Beheben von Problemen mit benutzerdefinierten Richtlinien und Benutzerflows in Azure AD B2C

Fehler beim Zurücksetzen des Kennworts

Dieser Fehler tritt auf, wenn die Self-Service-Kennwortzurücksetzung in einem Benutzerflow nicht aktiviert ist. Bei Auswahl des Links Kennwort vergessen? wird kein Benutzerflow für die Kennwortzurücksetzung ausgelöst. Stattdessen wird der Fehlercode AADB2C90118 an Ihre Anwendung zurückgegeben.

Es gibt zwei Lösungen für dieses Problem:

• Antwort mit einer neuen Authentifizierungsanforderung über den Azure AD B2C-Benutzerflow für die Kennwortzurücksetzung.
  • Verwenden Sie die empfohlene Self-Service-Kennwortzurücksetzung (Self-Service Password Reset, SSPR).

Der Benutzer hat den Vorgang abgebrochen.

Der Azure AD B2C-Dienst kann auch einen Fehler an Ihre Anwendung zurückgeben, wenn ein Benutzer einen Vorgang abbricht. Im Folgenden sind Beispiele für Szenarien aufgeführt, in denen ein Benutzer einen Abbruchvorgang ausführt:

• Eine Benutzerrichtlinie verwendet die empfohlene Self-Service-Kennwortzurücksetzung (Self-Service Password Reset, SSPR) mit einem lokalen Consumerkonto. Der Benutzer wählt den Link "Kennwort vergessen?" aus und wählt dann die Schaltfläche " Abbrechen " aus, bevor die Benutzerablauferfahrung abgeschlossen ist. In diesem Fall gibt der Azure AD B2C-Dienst Fehlercode AADB2C90091 an Ihre Anwendung zurück.
• Ein Benutzer entscheidet sich für die Authentifizierung bei einem externen Identitätsanbieter wie LinkedIn. Der Benutzer wählt die Schaltfläche "Abbrechen " aus, bevor er sich für den Identitätsanbieter authentifiziert. In diesem Fall gibt der Azure AD B2C-Dienst Fehlercode AADB2C90273 an Ihre Anwendung zurück. Erfahren Sie mehr über vom Azure Active Directory B2C-Dienst zurückgegebene Fehlercodes.

Um diesen Fehler zu behandeln, rufen Sie die Fehlerbeschreibung für den Benutzer ab, und antworten Sie mit einer neuen Authentifizierungsanforderung mit demselben Benutzerablauf.

Wenn Sie benutzerdefinierte Azure Active Directory B2C(Azure AD B2C)-Richtlinien verwenden, treten möglicherweise Probleme mit dem XML-Format oder Laufzeitproblemen der Richtliniensprache auf. In diesem Artikel werden einige Tools und Tipps beschrieben, mit denen Sie Probleme ermitteln und beheben können.

Dieser Artikel befasst sich mit der Problembehandlung ihrer benutzerdefinierten Azure AD B2C-Richtlinienkonfiguration. Die Anwendung der vertrauenden Seite und die dazugehörige Identitätsbibliothek werden nicht behandelt.

Übersicht über die Azure AD B2C-Korrelations-ID

Die Korrelations-ID von Azure AD B2C ist ein eindeutiger Bezeichnerwert, der an Autorisierungsanforderungen angefügt ist. Er durchläuft alle Orchestrierungsschritte, die ein Benutzer durchläuft. Mit der Korrelations-ID können Sie:

• Identifizieren Sie die Anmeldeaktivität in Ihrer Anwendung, und verfolgen Sie die Leistungsfähigkeit Ihrer Richtlinie.
• Suchen Sie nach den Azure Application Insights-Protokollen für die Anmeldeanforderungen.
• Übergeben Sie die Korrelations-ID an Ihre REST-API, und verwenden Sie sie, um den Anmeldefluss zu identifizieren.

Die Korrelations-ID wird jedes Mal geändert, wenn eine neue Sitzung eingerichtet wird. Achten Sie beim Debuggen Ihrer Richtlinien darauf, dass Sie vorhandene Browserregisterkarten schließen oder einen neuen Browser im privaten Modus öffnen.

Voraussetzungen

• Führen Sie die Schritte in Erste Schritte mit benutzerdefinierten Richtlinien in Active Directory B2C aus.

Holen Sie sich die Azure AD B2C-Korrelations-ID

Sie finden die Korrelations-ID auf der Azure AD B2C-Anmelde- oder Anmeldeseite. Wählen Sie in Ihrem Browser die Ansichtsquelle aus. Die Korrelation wird oben auf der Seite als Kommentar angezeigt.

Kopieren Sie die Korrelations-ID, und fahren Sie dann mit dem Anmeldevorgang fort. Verwenden Sie die Korrelations-ID, um das Anmeldeverhalten zu beobachten. Weitere Informationen finden Sie unter "Problembehandlung mit Application Insights".

Echoanforderung der Korrelations-ID von Azure AD B2C

Sie können die Korrelations-ID in Ihre Azure AD B2C-Token einschließen. So fügen Sie die Korrelations-ID ein:

1. Öffnen Sie die Erweiterungsdatei Ihrer Richtlinie. Beispiel: SocialAndLocalAccounts/TrustFrameworkExtensions.xml.

2. Suchen Sie nach dem BuildingBlocks-Element . Wenn das Element nicht vorhanden ist, fügen Sie es hinzu.

3. Suchen Sie das ClaimsSchema-Element . Wenn das Element nicht vorhanden ist, fügen Sie es hinzu.

4. Fügen Sie dem ClaimsSchema-Element den Korrelations-ID-Anspruch hinzu.

   <!-- 
   <BuildingBlocks>
     <ClaimsSchema> -->
       <ClaimType Id="correlationId">
         <DisplayName>correlation ID</DisplayName>
         <DataType>string</DataType>
       </ClaimType>
     <!-- 
     </ClaimsSchema>
   </BuildingBlocks>-->
   

5. Öffnen Sie die Datei der vertrauenden Seite Ihrer Richtlinie. Beispiel: SocialAndLocalAccounts/SignUpOrSignIn.xml Datei. Der Ausgabeanspruch wird nach einer erfolgreichen User Journey in das Token eingefügt und an die Anwendung gesendet. Ändern Sie das Element „Technisches Profil“ im Abschnitt „vertrauende Seite“, um correlationId als eine Ausgabeanspruch hinzuzufügen.

   <RelyingParty>
     <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
     <TechnicalProfile Id="PolicyProfile">
       <DisplayName>PolicyProfile</DisplayName>
       <Protocol Name="OpenIdConnect" />
       <OutputClaims>
         ...
         <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
       </OutputClaims>
       <SubjectNamingInfo ClaimType="sub" />
     </TechnicalProfile>
   </RelyingParty>
   

Problembehandlung mit Application Insights

Verwenden Sie Application Insights, um Probleme mit Ihren benutzerdefinierten Richtlinien zu diagnostizieren. Application Insights verfolgt die Aktivitäten der User Journey für Ihre benutzerdefinierten Richtlinien. Es bietet eine Möglichkeit, Ausnahmen zu diagnostizieren und den Austausch von Ansprüchen zwischen Azure AD B2C und den verschiedenen Anspruchsanbietern zu beobachten. Die Anspruchsanbieter werden durch technische Profile definiert, z. B. Identitätsanbieter, API-basierte Dienste, das Azure AD B2C-Benutzerverzeichnis und andere Dienste.

Es wird empfohlen, die Azure AD B2C-Erweiterung für VS Code zu installieren. Mit der Azure AD B2C-Erweiterung werden die Protokolle nach Richtlinienname, Korrelations-ID (Application Insights zeigt die erste Ziffer der Korrelations-ID) und Protokollzeitstempel organisiert. Dieses Feature hilft Ihnen, das relevante Protokoll basierend auf dem lokalen Zeitstempel zu finden und die Benutzerreise wie von Azure AD B2C ausgeführt zu sehen.

Ein einzelner Anmeldeflow kann mehr als eine Azure Application Insights-Ablaufverfolgung ausgeben. Im folgenden Screenshot enthält die richtlinie B2C_1A_signup_signin drei Protokolle. Jedes Protokoll stellt einen Teil des Anmeldeflusses dar.

Der folgende Screenshot zeigt die Azure AD B2C-Erweiterung für VS Code mit Azure Application Insights-Ablaufverfolgungs-Explorer.

Filtern des Ablaufverfolgungsprotokolls

Mit dem Fokus auf dem Azure AD B2C-Ablaufverfolgungs-Explorer beginnen Sie mit der Eingabe der ersten Ziffer der Korrelations-ID oder einer Uhrzeit, die Sie finden möchten. Oben rechts im Azure AD B2C-Ablaufverfolgungs-Explorer wird ein Filterfeld angezeigt, das anzeigt, was Sie bisher eingegeben haben, und übereinstimmende Ablaufverfolgungsprotokolle sind hervorgehoben.

Wenn Sie mit dem Mauszeiger auf das Filterfeld zeigen und "Filter für Typ aktivieren" auswählen , werden nur übereinstimmende Ablaufverfolgungsprotokolle angezeigt. Verwenden Sie die Schaltfläche "X" zum Löschen des Filters.

Details des Application Insight-Ablaufverfolgungsprotokolls

Wenn Sie eine Azure Application Insights-Ablaufverfolgung auswählen, öffnet die Erweiterung das Fenster "Application Insights-Details " mit den folgenden Informationen:

• Application Insights – Allgemeine Informationen zum Ablaufverfolgungsprotokoll, einschließlich Richtlinienname, Korrelations-ID, Azure Application Insights-Ablaufverfolgungs-ID und Zeitstempel der Ablaufverfolgung.
• Technische Profile – Liste der technischen Profile, die im Ablaufverfolgungsprotokoll angezeigt werden.
• Ansprüche – Alphabetische Liste der Ansprüche, die im Ablaufprotokoll erscheinen, zusammen mit ihren Werten. Wenn ein Anspruch im Ablaufverfolgungsprotokoll mehrmals mit unterschiedlichen Werten angezeigt wird, bestimmt ein => Zeichen den neuesten Wert. Sie können diese Ansprüche überprüfen, um festzustellen, ob erwartete Anspruchswerte richtig festgelegt sind. Wenn Sie z. B. über eine Voraussetzung verfügen, die einen Anspruchswert überprüft, können Sie im Abschnitt "Ansprüche" ermitteln, warum sich ein erwarteter Fluss anders verhält.
• Anspruchstransformation: Liste der Anspruchstransformationen, die im Ablaufverfolgungsprotokoll angezeigt werden. Jede Anspruchstransformation enthält die Eingabeansprüche, Eingabeparameter und Ausgabeansprüche. Der Abschnitt "Forderungstransformation" bietet Einblicke in die gesendeten Daten und das Ergebnis der Anspruchstransformation.
• Token: Liste der Token, die im Ablaufverfolgungsprotokoll angezeigt werden. Die Token enthalten die zugrunde liegenden Verbund-OAuth- und OpenId Connect-Identitätsanbietertoken. Das Token des föderierten Identitätsanbieters enthält Details dazu, wie der Identitätsanbieter die Ansprüche an Azure AD B2C zurückgibt; so können Sie die technischen Profilansprüche des Identitätsanbieters zuordnen.
• Ausnahmen: Liste der Ausnahmen oder schwerwiegenden Fehler, die im Ablaufverfolgungsprotokoll angezeigt werden.
• Application Insights JSON – Die Rohdaten, die von den Application Insights zurückgegeben werden.

Der folgende Screenshot enthält ein Beispielfenster mit Details des Application Insights-Ablaufverfolgungsprotokolls.

Problembehandlung von JWTs

Für JWT-Überprüfungs- und Debuggingzwecke können JWTs mithilfe einer Website wie https://jwt.msz. B. decodiert werden. Erstellen Sie eine Testanwendung, die Sie zur Tokenüberprüfung an https://jwt.ms weiterleiten kann. Wenn dies noch nicht geschehen ist, registrieren Sie eine Webanwendung, und aktivieren Sie die implizite Gewährung von ID-Token.

Verwenden Sie "Jetzt ausführen" und testen Sie https://jwt.ms Ihre Richtlinien unabhängig von Ihrer Web- oder mobilen Anwendung. Diese Website verhält sich wie eine Anwendung der vertrauenden Seite. Es zeigt den Inhalt des JSON-Webtokens (JWT) an, den Ihre Azure AD B2C-Richtlinie generiert.

Problembehandlung des SAML-Protokolls

Um die Integration mit Ihrem Dienstanbieter zu konfigurieren und zu debuggen, können Sie eine Browsererweiterung für das SAML-Protokoll verwenden, z. B. SAML DevTools-Erweiterung für Chrome, SAML-Tracer für Firefox oder Edge oder Internet Explorer-Entwicklertools.

Der folgende Screenshot zeigt, wie die SAML DevTools-Erweiterung die SAML-Anforderung Azure AD B2C darstellt, die an den Identitätsanbieter gesendet wird, und die SAML-Antwort.

Mithilfe dieser Tools können Sie die Integration zwischen Ihrer Anwendung und Azure AD B2C überprüfen. Beispiel:

• Überprüfen Sie, ob die SAML-Anforderung eine Signatur enthält, und bestimmen Sie, welcher Algorithmus für die Anmeldung bei der Autorisierungsanforderung verwendet wird.
• Überprüfen Sie, ob Azure AD B2C eine Fehlermeldung zurückgibt.
• Überprüfen Sie, ob der Assertionsabschnitt verschlüsselt ist.
• Rufen Sie den Namen der Ansprüche ab, die vom Identitätsanbieter zurückgegeben werden.

Sie können auch den Austausch von Nachrichten zwischen Ihrem Clientbrowser und Azure AD B2C mit Fiddler nachverfolgen. So erhalten Sie Hinweise dazu, an welcher Stelle für Ihre User Journey in den Orchestrierungsschritten ein Fehler auftritt.

Behandeln von Problemen mit der Gültigkeit von Richtlinien

Nachdem Sie die Entwicklung Ihrer Richtlinie abgeschlossen haben, laden Sie die Richtlinie in Azure AD B2C hoch. Möglicherweise gibt es einige Probleme mit Ihrer Richtlinie, Aber Sie können Ihre Richtlinie überprüfen, bevor Sie sie hochladen.

Der häufigste Fehler beim Einrichten von benutzerdefinierten Richtlinien ist falsch formatiertes XML. Ein guter XML-Editor ist fast unerlässlich. Es zeigt XML nativ an, weist Inhalt farbig aus, füllt allgemeine Begriffe vorab aus, hält XML-Elemente im Index und kann gegen ein XML-Schema validiert werden.

Es wird empfohlen , Visual Studio Code zu verwenden. Installieren Sie dann eine XML-Erweiterung, z. B. die XML-Sprachunterstützung von Red Hat. Mit der XML-Erweiterung können Sie das XML-Schema überprüfen, bevor Sie Ihre XML-Datei mithilfe der XSD-Schemadefinition für benutzerdefinierte Richtlinien hochladen.

Sie können die XML-Dateizuordnungsstrategie verwenden, um die XML-Datei an die XSD zu binden, indem Sie der VS Code-Datei settings.json die folgenden Einstellungen hinzufügen. Gehen Sie folgendermaßen vor:

1. Wählen Sie in VS Code die Optionen Datei>Einstellungen>Einstellungen aus. Weitere Informationen finden Sie unter "Benutzer- und Arbeitsbereichseinstellungen".

2. Suchen Sie nach fileAssociations und wählen Sie dann unter der Erweiterung das XML aus.

3. Wählen Sie "In settings.jsonbearbeiten" aus .

   

4. Fügen Sie im settings.jsonden folgenden JSON-Code hinzu:

   "xml.fileAssociations": [
     {
       "pattern": "**.xml",
       "systemId": "https://raw.githubusercontent.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/master/TrustFrameworkPolicy_0.3.0.0.xsd"
     }
   ]
   

5. Speichern Sie die Änderungen.

Das folgende Beispiel zeigt einen XML-Überprüfungsfehler. Wenn Sie mit der Maus über den Elementnamen navigieren, werden die erwarteten Elemente in der Erweiterungsliste aufgeführt.

Im folgenden Fall ist das DisplayName Element richtig. Aber in der falschen Reihenfolge. Dies DisplayName sollte vor dem Protocol Element sein. Um das Problem zu beheben, bewegen Sie Ihre Maus über das DisplayName Element und ordnen Sie die Elemente in die richtige Reihenfolge.

Hochladen von Richtlinien und Richtlinienüberprüfung

Die Überprüfung der XML-Richtliniendatei wird automatisch beim Hochladen ausgeführt. Die meisten Fehler führen dazu, dass der Upload fehlschlägt. Die Validierung schließt die Richtliniendatei ein, die Sie hochladen möchten. Sie enthält auch die Kette der Dateien, auf die sich die Uploaddatei bezieht (die Richtliniendatei der vertrauenden Seite, die Erweiterungsdatei und die Basisdatei).

Dieser Abschnitt enthält die allgemeinen Überprüfungsfehler und wahrscheinlichen Lösungen.

Schemaüberprüfungsfehler gefunden ... hat ein ungültiges Kind-Element '{name}'

Ihre Richtlinie enthält ein ungültiges XML-Element, oder das XML-Element ist gültig, scheint jedoch in der falschen Reihenfolge zu sein. Informationen zum Beheben dieses Fehlertyps finden Sie im Abschnitt "Problembehandlung für die Richtliniengültigkeit ".

Es gibt eine doppelte Schlüsselsequenz "{number}"

Eine Benutzerreise oder Unterreise besteht aus einer sortierten Liste der Orchestrierungsschritte, die in Sequenz ausgeführt werden. Nachdem Sie Ihre Reise geändert haben, berechnen Sie die Schritte sequenziell neu, ohne ganze Zahlen zwischen 1 und N zu überspringen.

...in der Reihenfolge wurde der Schritt „{Zahl}“ erwartet, aber nicht gefunden...

Überprüfen Sie den vorherigen Fehler.

Auf den Orchestrierungsschritt '{Zahl}' in User Journey '{Name}' ... folgt ein Schritt zur Auswahl des Anspruchsanbieters, der den Typ „ClaimsExchange“ aufweisen muss. Der Typ ist aber ...

Der Orchestrierungsschritttyp von ClaimsProviderSelection und CombinedSignInAndSignUp enthält eine Liste von Optionen, aus denen ein Benutzer auswählen kann. Darauf muss der Typ ClaimsExchange mit mindestens einem Anspruchsaustausch folgen.

Die folgenden Orchestrierungsschritte verursachen diesen Typ oder Fehler. Der zweite Orchestrierungsschritt muss vom Typ ClaimsExchange sein, nicht ClaimsProviderSelection.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
        <ClaimsProviderSelections>
          <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange"/>
          <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange"/>
        </ClaimsProviderSelections>
        <ClaimsExchanges>
          <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email"/>
        </ClaimsExchanges>
      </OrchestrationStep> 

      <OrchestrationStep Order="2" Type="ClaimsProviderSelection">
        ...
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

... Schritt {Zahl} mit 2 Anspruchsaustauschvorgängen. Es muss einer Auswahl eines Anspruchsanbieters vorangestellt werden, um zu bestimmen, welche Anspruchsbörse verwendet werden kann.

Ein Orchestrierungsschritttyp ClaimsExchange muss einen einzelnen ClaimsExchange haben, es sei denn, der vorherige Schritt ist vom Typ ClaimsProviderSelection oder CombinedSignInAndSignUp. Die folgenden Orchestrierungsschritte verursachen diesen Fehlertyp. Der sechste Schritt enthält zwei Anspruchsaustausche.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Verwenden Sie zwei Orchestrierungsschritte, um diesen Fehlertyp zu beheben. Jeder Orchestrierungsschritt enthält einen Anspruchsaustausch.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Es gibt eine doppelte Schlüsselsequenz "{name}"

Eine Journey weist mehr als einen ClaimsExchange mit derselben Id auf. Die folgenden Schritte verursachen diesen Fehlertyp. Die ID AADUserWrite wird zweimal auf der Benutzerreise angezeigt.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Um diese Art von Fehler zu beheben, ändern Sie den Anspruchsaustausch im achten Orchestrierungsschritt in einen eindeutigen Namen, z. B. Call-REST-API.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-API" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

... verweist auf "ClaimType" mit der ID "{claim name}", aber weder die Richtlinie noch eine der Basisrichtlinien enthalten ein solches Element.

Dieser Fehlertyp tritt auf, wenn Ihre Richtlinie einen Verweis auf einen Anspruch vorgibt, der nicht im Anspruchsschema deklariert ist. Ansprüche müssen in mindestens einer der Dateien in der Richtlinie definiert werden.

Beispiel: technisches Profil mit dem Ausgabeanspruch schoolId. Der Ausgabeanspruch "schoolId " wird jedoch nie in der Richtlinie oder in einer Vorgängerrichtlinie deklariert.

<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="schoolId" />
  ...
</OutputClaims>

Um diesen Fehlertyp zu beheben, überprüfen Sie, ob der ClaimTypeReferenceId Wert falsch geschrieben ist oder im Schema nicht vorhanden ist. Wenn der Anspruch in der Erweiterungsrichtlinie definiert ist, aber auch in der Basisrichtlinie verwendet wird. Stellen Sie sicher, dass der Anspruch in der Richtlinie definiert ist, in der er verwendet wird, oder in einer Richtlinie auf oberster Ebene.

Das Hinzufügen des Anspruchs zum Anspruchsschema löst diesen Fehlertyp.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="schoolId">
      <DisplayName>School name</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Enter your school name</UserHelpText>
      <UserInputType>TextBox</UserInputType>
    </ClaimType>
  <!-- 
  </ClaimsSchema>
</BuildingBlocks> -->

... verweist auf eine Anspruchstransformation mit ID...

Die Ursache für diesen Fehler ähnelt der Ursache für den Anspruchsfehler. Überprüfen Sie den vorherigen Fehler.

Der Benutzer ist derzeit als Benutzer des Mandanten "yourtenant.onmicrosoft.com" angemeldet.

Sie melden sich mit einem Konto von einem Mandanten an, der sich von der Richtlinie unterscheidet, die Sie hochladen möchten. Zum Beispiel erfolgt Ihre Anmeldung mit admin@contoso.onmicrosoft.com, während Ihre Richtlinie TenantId auf fabrikam.onmicrosoft.com gesetzt ist.

<TrustFrameworkPolicy ...
  TenantId="fabrikam.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin"
  PublicPolicyUri="http://fabrikam.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>fabrikam.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>
  ...
</TrustFrameworkPolicy>

• Überprüfen Sie, ob der TenantId-Wert in den <TrustFrameworkPolicy\>- und <BasePolicy\>-Elementen mit Ihrem Azure AD B2C-Zielmandanten übereinstimmt.

Der Anspruchstyp '{Name}' ist der Ausgabeanspruch des technischen Profils der vertrauenden Seite, aber kein Ausgabeanspruch in einem der Schritte der User Journey...

In einer Richtlinie für die vertrauende Seite haben Sie einen Ausgabeanspruch hinzugefügt, aber dieser Ausgabeanspruch ist in keinem der Schritte der User Journey vorhanden. Azure AD B2C kann den Anspruchswert nicht aus dem Anspruchsbehälter lesen.

Im folgenden Beispiel ist der Anspruch "schoolId" ein Ausgabeanspruch des technischen Profils der vertrauenden Seite, es handelt sich jedoch nicht um einen Ausgabeanspruch in einem der Schritte des SignUpOrSignIn-Benutzerflusses.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="schoolId" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Um diese Art von Fehler zu beheben, stellen Sie sicher, dass die Ausgabeansprüche in mindestens einer Sammlung der Ausgabeansprüche des technischen Profils für die Orchestrierungsschritte angezeigt werden. Wenn Ihre User Journey den Anspruch nicht ausgeben kann, legen Sie im technischen Profil der vertrauenden Seite einen Standardwert fest, z. B. eine leere Zeichenfolge.

<OutputClaim ClaimTypeReferenceId="schoolId" DefaultValue="" />

Die Eingabezeichenfolge hat das falsche Format

Sie legen einen falschen Werttyp auf einen Anspruch eines anderen Typs fest. Beispielsweise definieren Sie einen ganzzahligen Anspruch.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="age">
      <DisplayName>Age</DisplayName>
      <DataType>int</DataType>
    </ClaimType>
  <!--
  </ClaimsSchema>
</BuildingBlocks> -->

Anschließend versuchen Sie, einen Zeichenfolgenwert festzulegen:

<OutputClaim ClaimTypeReferenceId="age" DefaultValue="ABCD" />

Um diesen Fehlertyp zu beheben, stellen Sie sicher, dass Sie den richtigen Wert festlegen, wie z. B. DefaultValue="0".

Für Mandant '{Name}' gibt es bereits eine Richtlinie mit ID '{Name}'. Eine andere Richtlinie mit derselben ID kann nicht gespeichert werden.

Sie versuchen, eine Richtlinie für Ihren Mandanten hochzuladen, aber eine Richtlinie mit demselben Namen ist bereits hochgeladen.

Wenn Sie diese Art von Fehler beheben möchten, aktivieren Sie beim Hochladen der Richtlinie das Kontrollkästchen "Benutzerdefinierte Richtlinie überschreiben", wenn sie bereits vorhanden ist .