Felsöka anpassade azure AD B2C-principer och användarflöden

Innan du börjar använder du väljaren Välj en principtyp för att välja den typ av princip som du konfigurerar. Azure Active Directory B2C erbjuder två metoder för att definiera hur användare interagerar med dina program: via fördefinierade användarflöden eller genom fullständigt konfigurerbara anpassade principer. De steg som krävs i den här artikeln skiljer sig åt för varje metod.

Ditt program måste hantera vissa fel som kommer från Azure B2C-tjänsten. Den här artikeln belyser några av de vanliga felen och hur du hanterar dem.

Fel vid lösenordsåterställning

Det här felet uppstår när självbetjäningsfunktionen för lösenordsåterställning inte är aktiverad i ett användarflöde. Om du väljer länken Har du glömt lösenordet? utlöser inte användarflödet för lösenordsåterställning. I stället returneras felkoden AADB2C90118 till ditt program.

Det finns två lösningar på det här problemet:

• Svara tillbaka med en ny autentiseringsbegäran med hjälp av användarflödet för azure AD B2C-lösenordsåterställning.
• Använd rekommenderad SSPR-upplevelse (självbetjäning av lösenordsåterställning).

Användaren avbröt åtgärden

Azure AD B2C-tjänsten kan också returnera ett fel till ditt program när en användare avbryter en åtgärd. Följande är exempel på scenarier där en användare utför en avbruten åtgärd:

• En användarprincip använder den rekommenderade SSPR-upplevelsen (self service password reset) med ett lokalt konsumentkonto. Användaren väljer länken Har du glömt lösenordet? och väljer sedan knappen Avbryt innan användarflödesupplevelsen är klar. I det här fallet returnerar Azure AD B2C-tjänsten felkod AADB2C90091 till ditt program.
• En användare väljer att autentisera med en extern identitetsprovider, till exempel LinkedIn. Användaren väljer knappen Avbryt innan den autentiserar till själva identitetsprovidern. I det här fallet returnerar Azure AD B2C-tjänsten felkod AADB2C90273 till ditt program. Läs mer om felkoder för Azure Active Directory B2C-tjänstretur.

Om du vill hantera det här felet hämtar du felbeskrivningen för användaren och svarar med en ny autentiseringsbegäran med samma användarflöde.

Om du använder anpassade principer för Azure Active Directory B2C (Azure AD B2C) kan det uppstå problem med XML-format för principspråk eller körningsproblem. Den här artikeln beskriver några verktyg och tips som kan hjälpa dig att identifiera och lösa problem.

Den här artikeln fokuserar på att felsöka konfigurationen av din anpassade Azure AD B2C-princip. Den hanterar inte det förlitande partprogrammet eller dess identitetsbibliotek.

Översikt över Korrelations-ID för Azure AD B2C

Korrelations-ID för Azure AD B2C är ett unikt identifierarvärde som är kopplat till auktoriseringsbegäranden. Den går igenom alla orkestreringssteg som en användare går igenom. Med korrelations-ID:t kan du:

• Identifiera inloggningsaktiviteten i ditt program och spåra principens prestanda.
• Leta upp inloggningsbegärans Azure Application Insights-loggar.
• Skicka korrelations-ID:t till rest-API:et och använd det för att identifiera inloggningsflödet.

Korrelations-ID ändras varje gång en ny session upprättas. När du felsöker dina principer kontrollerar du att du stänger befintliga webbläsarflikar eller öppnar en ny webbläsare i privat läge.

Förutsättningar

• Slutför stegen i Kom igång med anpassade principer i Active Directory B2C.

Hämta korrelations-ID:t för Azure AD B2C

Du hittar korrelations-ID:t på registrerings- eller inloggningssidan för Azure AD B2C. I webbläsaren väljer du Visa källa. Korrelationen visas som en kommentar överst på sidan.

Kopiera korrelations-ID:t och fortsätt sedan inloggningsflödet. Använd korrelations-ID:t för att observera inloggningsbeteendet. Mer information finns i Felsökning med Application Insights.

Upprepa korrelations-ID:t för Azure AD B2C

Du kan inkludera korrelations-ID:t i dina Azure AD B2C-token. Så här inkluderar du korrelations-ID:t:

1. Öppna tilläggsfilen för principen. Exempel: SocialAndLocalAccounts/TrustFrameworkExtensions.xml

2. Sök efter elementet BuildingBlocks . Om elementet inte finns lägger du till det.

3. Leta upp elementet ClaimsSchema . Om elementet inte finns lägger du till det.

4. Lägg till korrelations-ID-anspråket i elementet ClaimsSchema .

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

5. Öppna den förlitande partfilen för principen. Till exempel SocialAndLocalAccounts/SignUpOrSignIn.xml fil. Utdataanspråket läggs till i token efter en lyckad användarresa och skickas till programmet. Ändra det tekniska profilelementet i avsnittet förlitande part för att lägga correlationId till som ett utdataanspråk.

   <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>
   

Felsökning med Application Insights

Om du vill diagnostisera problem med dina anpassade principer använder du Application Insights. Application Insights spårar aktiviteten för din anpassade principanvändares resa. Det är ett sätt att diagnostisera undantag och observera utbytet av anspråk mellan Azure AD B2C och de olika anspråksprovidrar. Anspråksprovidrar definieras av tekniska profiler, till exempel identitetsprovidrar, API-baserade tjänster, Azure AD B2C-användarkatalogen och andra tjänster.

Vi rekommenderar att du installerar Azure AD B2C-tillägget för VS Code. Med Azure AD B2C-tillägget ordnas loggarna efter principnamn, korrelations-ID (Application Insights visar den första siffran i korrelations-ID:t) och loggtidsstämpeln. Den här funktionen hjälper dig att hitta relevant logg baserat på den lokala tidsstämpeln och se användarresan som körs av Azure AD B2C.

Kommentar

• Det är en kort fördröjning, vanligtvis mindre än fem minuter, innan du kan se nya loggar i Application Insights.
• Communityn har utvecklat Visual Studio Code-tillägget för Azure AD B2C för att hjälpa identitetsutvecklare. Tillägget stöds inte av Microsoft och görs strikt tillgängligt som det är.

Ett flöde för enkel inloggning kan utfärda mer än en Azure Application Insights-spårning. I följande skärmbild har principen B2C_1A_signup_signin tre loggar. Varje logg representerar en del av inloggningsflödet.

Följande skärmbild visar Azure AD B2C-tillägget för VS Code med Azure Application Insights-spårningsutforskaren.

Filtrera spårningsloggen

Med fokus på Azure AD B2C-spårningsutforskaren börjar du skriva den första siffran i korrelations-ID:t eller en tid som du vill hitta. Du ser en filterruta längst upp till höger i Azure AD B2C-spårningsutforskaren som visar vad du har skrivit hittills och matchande spårningsloggar är markerade.

Om du hovrar över filterrutan och väljer Aktivera filter på typ visas endast matchande spårningsloggar. Använd knappen "X" Rensa för att rensa filtret.

Application Insights-spårningslogginformation

När du väljer en Azure Application Insights-spårning öppnar tillägget informationsfönstret Application Insights med följande information:

• Application Insights – Allmän information om spårningsloggen , inklusive principnamn, korrelations-ID, Azure Application Insights-spårnings-ID och spårningstidsstämpel.
• Tekniska profiler – Lista över tekniska profiler som visas i spårningsloggen.
• Anspråk – alfabetisk lista över anspråk som visas i spårningsloggen och deras värden. Om ett anspråk visas i spårningsloggen flera gånger med olika värden, anger ett => tecken det senaste värdet. Du kan granska dessa anspråk för att avgöra om förväntade anspråksvärden har angetts korrekt. Om du till exempel har en förutsättning som kontrollerar ett anspråksvärde kan anspråksavsnittet hjälpa dig att avgöra varför ett förväntat flöde beter sig annorlunda.
• Anspråkstransformering – Lista över anspråkstransformeringar som visas i spårningsloggen. Varje anspråkstransformering innehåller indataanspråk, indataparametrar och utdataanspråk. Avsnittet om anspråkstransformering ger insikter om de data som skickas in och resultatet av anspråkstransformeringen.
• Tokens – lista över token som visas i spårningsloggen. Token inkluderar den underliggande federerade OAuth och OpenId Anslut identitetsproviderns token. Den federerade identitetsproviderns token ger information om hur identitetsprovidern returnerar anspråken till Azure AD B2C så att du kan mappa utdataanspråk för identitetsproviderns tekniska profil.
• Undantag – Lista över undantag eller allvarliga fel som visas i spårningsloggen.
• Application Insights JSON – Rådata som returneras från Application Insights.

Följande skärmbild visar ett exempel på application insights-spårningsloggens informationsfönster.

Felsöka JWT-token

För validering och felsökning av JWT-token kan du avkoda JWT:er med hjälp av en webbplats som https://jwt.ms. Skapa ett testprogram som kan omdirigeras till https://jwt.ms för tokenkontroll. Om du inte redan har gjort det registrerar du ett webbprogram och aktiverar implicit beviljande av ID-token.

Använd Kör nu och https://jwt.ms för att testa dina principer oberoende av ditt webb- eller mobilprogram. Den här webbplatsen fungerar som ett förlitande partprogram. Den visar innehållet i JSON-webbtoken (JWT) som din Azure AD B2C-princip genererar.

Felsöka SAML-protokoll

För att konfigurera och felsöka integreringen med tjänstleverantören kan du använda ett webbläsartillägg för SAML-protokollet, till exempel SAML DevTools-tillägget för Chrome, SAML-tracer för FireFox eller Edge eller IE Utvecklarverktyg.

Följande skärmbild visar hur SAML DevTools-tillägget visar SAML-begäran som Azure AD B2C skickar till identitetsprovidern och SAML-svaret.

Med de här verktygen kan du kontrollera integreringen mellan ditt program och Azure AD B2C. Till exempel:

• Kontrollera om SAML-begäran innehåller en signatur och avgör vilken algoritm som används för att logga in auktoriseringsbegäran.
• Kontrollera om Azure AD B2C returnerar ett felmeddelande.
• Kontrollera om kontrollavsnittet är krypterat.
• Hämta namnet på anspråken som returnerar identitetsprovidern.

Du kan också spåra utbytet av meddelanden mellan klientwebbläsaren och Azure AD B2C med Fiddler. Det kan hjälpa dig att få en indikation på var din användarresa misslyckas i orkestreringsstegen.

Felsöka princip giltighet

När du har utvecklat principen laddar du upp principen till Azure AD B2C. Det kan finnas vissa problem med din princip, men du kan validera principen innan du laddar upp den.

Det vanligaste felet vid konfiguration av anpassade principer är felaktigt formaterad XML. En bra XML-redigerare är nästan nödvändig. Den visar XML-inbyggt, färgkodsinnehåll, förfyller vanliga termer, håller XML-element indexerade och kan verifiera mot ett XML-schema.

Vi rekommenderar att du använder Visual Studio Code. Installera sedan ett XML-tillägg, till exempel XML Language Support by Red Hat. Med XML-tillägget kan du verifiera XML-schemat innan du laddar upp XML-filen med hjälp av XSD-schemadefinitionen för anpassad princip.

Du kan använda XML-filassociationsstrategin för att binda XML-filen till XSD genom att lägga till följande inställningar i VS Code-filen settings.json . Så här gör du:

1. I VS Code väljer du Filinställningar>> Inställningar. Mer information finns i Inställningar för användare och arbetsyta.

2. Sök efter fileAssociations och välj sedan XML under tillägget.

3. Välj Redigera i settings.json.

   

4. Lägg till följande JSON-kod i settings.json:

   "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. Spara ändringarna.

I följande exempel visas ett XML-verifieringsfel. När du flyttar musen över elementnamnet listar tillägget de förväntade elementen.

I följande fall är elementet DisplayName korrekt. Men i fel ordning. DisplayName Ska vara före elementetProtocol. Lös problemet genom att flytta musen över elementet DisplayName till rätt ordning för elementen.

Ladda upp principer och principverifiering

Verifiering av XML-principfilen utförs automatiskt vid uppladdning. De flesta fel gör att uppladdningen misslyckas. Valideringen innehåller den principfil som du vill ladda upp. Den innehåller också kedjan med filer som uppladdningsfilen refererar till (den förlitande partens principfil, filnamnstilläggen och basfilen).

Dricks

Azure AD B2C kör ytterligare validering för förlitande partprincip. När du har problem med din princip, även om du bara redigerar tilläggsprincipen, är det en bra idé att även ladda upp principen för förlitande part.

Det här avsnittet innehåller vanliga valideringsfel och troliga lösningar.

Schemaverifieringsfel hittades ... har det ogiltiga underordnade elementet {name}

Principen innehåller ett ogiltigt XML-element, eller så är XML-elementet giltigt, men verkar vara i fel ordning. Om du vill åtgärda den här typen av fel läser du avsnittet Felsöka princip giltighet .

Det finns en duplicerad nyckelsekvens {number}

En användarresaeller underresa består av en ordnad lista över orkestreringssteg som körs i följd. När du har ändrat din resa numrerar du om stegen sekventiellt utan att hoppa över några heltal från 1 till N.

Dricks

Du kan använda Azure AD B2C-tillägget för VS Code-kommandot(Shift+Ctrl+r) för att numrera om alla orkestreringssteg för användarresor och underresor i din princip.

... förväntades ha steg med ordningen {number}, men det hittades inte...

Kontrollera föregående fel.

Orkestreringsstegordning "{number}" i användarresan "{name}" ... följs av ett urvalssteg för anspråksprovidern och måste vara ett anspråksutbyte, men det är av typen ...

Orkestreringsstegstypen ClaimsProviderSelectionoch CombinedSignInAndSignUp innehåller en lista med alternativ som en användare kan välja mellan. Den måste följa efter typ av ClaimsExchange med ett eller flera anspråksutbyte.

Följande orkestreringssteg orsakar den här typen eller felet. Det andra orkestreringssteget måste vara typen ClaimsExchange, inte 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> -->

... steg {number} med 2 anspråksutbyten. Det måste föregås av ett val av anspråksprovider för att avgöra vilka anspråksutbyte som kan användas

En orkestreringsstegtyp ClaimsExchange måste ha en enda ClaimsExchange, såvida inte föregående steg är typen ClaimsProviderSelection, eller CombinedSignInAndSignUp. Följande orkestreringssteg orsakar den här typen av fel. Det sjätte steget innehåller två anspråksutbyte.

<!-- 
<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> -->

Använd två orkestreringssteg för att åtgärda den här typen av fel. Varje orkestreringssteg med ett anspråksutbyte.

<!-- 
<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> -->

Det finns en duplicerad nyckelsekvens {name}

En resa har flera ClaimsExchange med samma Id. Följande steg orsakar den här typen av fel. ID:t AADUserWrite visas två gånger under användarresan.

<!-- 
<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> -->

Om du vill åtgärda den här typen av fel ändrar du den åttonde orkestreringsstegens anspråksutbyte till ett unikt namn, till exempel 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> -->

... refererar till ClaimType med ID :t {anspråksnamn}, men varken principen eller någon av dess basprinciper innehåller ett sådant element

Den här typen av fel inträffar när principen refererar till ett anspråk som inte deklareras i anspråksschemat. Anspråk måste definieras i minst en av filerna i principen.

Till exempel en teknisk profil med schoolId-utdataanspråket. Men utdataanspråkets schoolId deklareras aldrig i principen eller i en överordnad princip.

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

Åtgärda den här typen av fel genom att kontrollera om ClaimTypeReferenceId värdet är felstavat eller inte finns i schemat. Om anspråket definieras i tilläggsprincipen, men det används också i basprincipen. Kontrollera att anspråket har definierats i principen som det används i eller i en princip på den övre nivån.

Att lägga till anspråket i anspråksschemat löser den här typen av fel.

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

... refererar till en ClaimsTransformation med ID...

Orsaken till det här felet liknar den för anspråksfelet. Kontrollera föregående fel.

Användaren loggas för närvarande som användare av klientorganisationen "yourtenant.onmicrosoft.com" ...

Du loggar in med ett konto från en klientorganisation som skiljer sig från den princip som du försöker ladda upp. Du kan till exempel logga in med admin@contoso.onmicrosoft.com, medan principen TenantId är inställd på fabrikam.onmicrosoft.com.

<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>

• Kontrollera att TenantId värdet i elementen <TrustFrameworkPolicy\> och <BasePolicy\> matchar din Azure AD B2C-målklientorganisation.

Anspråkstypen {name} är utdataanspråket för den förlitande partens tekniska profil, men det är inte ett utdataanspråk i något av stegen i användarresan...

I en förlitande part-princip har du lagt till ett utdataanspråk, men utdataanspråket är inte ett utdataanspråk i något av stegen i användarresan. Azure AD B2C kan inte läsa anspråksvärdet från anspråkspåsen.

I följande exempel är schoolId-anspråket ett utdataanspråk för den förlitande partens tekniska profil, men det är inte ett utdataanspråk i något av stegen i SignUpOrSignIn-användarresan.

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

Om du vill åtgärda den här typen av fel kontrollerar du att utdataanspråken visas i minst ett orkestreringsstegs insamling av utdataanspråk för teknisk profil. Om din användarresa inte kan mata ut anspråket anger du ett standardvärde i den förlitande partens tekniska profil, till exempel tom sträng.

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

Indatasträngen var inte i rätt format

Du anger felaktig värdetyp till ett anspråk från en annan typ. Du kan till exempel definiera ett heltalsanspråk.

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

Sedan försöker du ange ett strängvärde:

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

Om du vill åtgärda den här typen av fel kontrollerar du att du anger rätt värde, till exempel DefaultValue="0".

Klientorganisationen {name} har redan en princip med ID :t {name}. Det går inte att lagra en annan princip med samma ID

Du försöker ladda upp en princip till klientorganisationen, men en princip med samma namn har redan laddats upp till din klientorganisation.

Om du vill åtgärda den här typen av fel markerar du kryssrutan Skriv över den anpassade principen om den redan finns när du laddar upp principen.

Nästa steg

• Lär dig hur du samlar in Azure Active Directory B2C-loggar med Application Insights.