Solucionar problemas de políticas personalizadas e fluxos do usuário do Azure AD B2C

Antes de começar, use o seletor Escolher um tipo de política para escolher o tipo de política que você está configurando. O Azure Active Directory B2C oferece dois métodos para definir como os usuários interagem com seus aplicativos: por meio de fluxos dos usuários predefinidos ou de políticas personalizadas totalmente configuráveis. As etapas necessárias neste artigo são diferentes para cada método.

Seu aplicativo precisa lidar com determinados erros provenientes do serviço do Azure B2C. Este artigo destaca alguns dos erros comuns e como lidar com eles.

Erro de redefinição de senha

Esse erro ocorre quando a experiência de redefinição de senha por autoatendimento não está habilitada em um fluxo do usuário. Portanto, selecionar o link Esqueceu sua senha? não dispara um fluxo do usuário de redefinição de senha. Em vez disso, o código de erro AADB2C90118 é retornado para seu aplicativo.

Existem duas soluções para esse problema:

• Responder com uma nova solicitação de autenticação usando o fluxo de usuário de redefinição de senha do Azure AD B2C.
• Usar a experiência de SSPR (redefinição de senha self-service) recomendada.

O usuário cancelou a operação

o serviço do Azure AD B2C também pode retornar um erro para seu aplicativo quando um usuário cancela uma operação. Veja a seguir exemplos de cenários em que um usuário executa uma operação de cancelamento:

• Uma política de usuário usa a experiência de SSPR (redefinição de senha self-service) recomendada com uma conta local de consumidor. O usuário seleciona o link Esqueceu sua senha?, em seguida, seleciona o botão Cancelar antes que a experiência de fluxo do usuário seja concluída. Nesse caso, o serviço do Azure AD B2C retorna o código de erro AADB2C90091 para o aplicativo.
• Um usuário opta por autenticar com um provedor de identidade externo, como o LinkedIn. O usuário seleciona o botão Cancelar antes de autenticar no próprio provedor de identidade. Nesse caso, o serviço do Azure AD B2C retorna o código de erro AADB2C90273 para o aplicativo. Saiba mais sobre os códigos de erro que o serviço do Azure Active Directory B2C retorna.

Para lidar com esse erro, busque a descrição de erro para o usuário e responda com uma nova solicitação de autenticação com o mesmo fluxo de usuário.

As políticas personalizadas do Azure Active Directory B2C (Azure AD B2C) oferecem desafios com o formato XML de linguagem de política ou problemas de runtime. Neste artigo, obtenha detalhes sobre as ferramentas e dicas que podem ajudar a identificar e resolver problemas.

Este artigo concentra-se na solução de problemas da configuração de política personalizada do Azure AD B2C. Ele não aborda o aplicativo de terceira parte confiável ou sua biblioteca de identidade.

Visão geral da ID de correlação do Azure AD B2C

A ID de correlação do Azure AD B2C é um valor de identificador exclusivo anexado às solicitações de autorização. Ela passa por todas as etapas de orquestração pelas quais um usuário passa. Com a ID de correlação, é possível:

• Identificar a atividade de conexão em seu aplicativo e acompanhar o desempenho de sua política.
• Encontrar os logs do Azure Application Insights relativos à solicitação de conexão.
• Transmitir a ID de correlação para a API REST e usá-la para identificar o fluxo de conexão.

A ID de correlação será alterada sempre que uma nova sessão for estabelecida. Ao depurar suas políticas, certifique-se de fechar as guias existentes do navegador ou abrir um novo navegador no modo privado.

Pré-requisitos

• Conclua as etapas em Introdução às políticas personalizadas no Active Directory B2C.

Obter a ID de correlação do Azure AD B2C

Encontre a ID de correlação na página de inscrição ou de conexão do Azure AD B2C. No navegador, selecione visualizar origem. A correlação aparece como um comentário na parte superior da página.

Copie a ID de correlação e continue o fluxo de conexão. Use a ID de correlação para observar o comportamento de conexão. Para obter mais informações, consulte Resolução de problemas do Application Insights.

Ecoar a ID de correlação do Azure AD B2C

É possível incluir a ID de correlação em seus tokens do Azure AD B2C. Para incluir a ID de correlação:

1. Abra o arquivo de extensões da sua política. Por exemplo, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.

2. Pesquise o elemento BuildingBlocks. Se o elemento não existir, adicione-o.

3. Localize o elemento ClaimsSchema. Se o elemento não existir, adicione-o.

4. Adicione a declaração da ID de correlação ao elemento ClaimsSchema.

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

5. Abra o arquivo de terceira parte confiável de sua política. Por exemplo, o arquivo SocialAndLocalAccounts/SignUpOrSignIn.xml. A declaração de saída será adicionada ao token após o percurso bem-sucedido do usuário e enviada ao aplicativo. Modifique o elemento de perfil técnico na seção da terceira parte confiável para adicionar correlationId como uma declaração de saída.

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

Solucionar problemas do Application Insights

Para diagnosticar problemas em suas políticas personalizadas, use o Application Insights. O Application Insights rastreia a atividade do percurso do usuário relacionado à política personalizada. Ele fornece uma maneira de diagnosticar as exceções e observar a troca de declarações entre o Azure AD B2C e os vários provedores de declarações. Os provedores de declarações são definidos por perfis técnicos, como provedores de identidade, serviços baseados em API, diretório de usuário do Azure AD B2C e outros serviços.

Recomenda-se instalar a extensão do Azure AD B2C para o VS Code. Com a extensão do Azure AD B2C, os logs são organizados por nome da política, ID de correlação (o primeiro dígito da ID de correlação é apresentado pelo Application Insights) e o carimbo de data/hora do log. Esse recurso ajuda a localizar logs relevantes com base no carimbo de data/hora local e ver o percurso do usuário, conforme executado pelo Azure AD B2C.

Observação

• Há um breve atraso (menos de cinco minutos) antes que você possa ver os novos logs no Application Insights.
• A comunidade desenvolveu a extensão Visual Studio Code para o Azure AD B2C a fim de ajudar os desenvolvedores de identidades. A extensão não tem suporte da Microsoft e é disponibilizada estritamente como se encontra.

Um fluxo de conexão único pode emitir mais de um rastreamento do Azure Application Insights. Na captura de tela a seguir, a política B2C_1A_signup_signin tem três logs. Cada log representa parte do fluxo de conexão.

A captura de tela a seguir mostra a extensão Azure AD B2C para VS Code com o gerenciador de rastreamento do Azure Application Insights.

Filtrar o log de rastreamento

Com o foco no gerenciador de rastreamento do Azure AD B2C, comece a digitar o primeiro dígito da ID de correlação ou uma hora que você deseja localizar. Você verá uma caixa de filtro à direita superior do gerenciador de rastreamento do Azure AD B2C com o texto digitado até o momento, e os logs de rastreamento correspondentes serão realçados.

Passar o mouse sobre a caixa de filtro e selecionar Habilitar filtro no tipo mostra somente os logs de rastreamento correspondentes. Use o botão Limpar 'X' para limpar o filtro.

Detalhes do log de rastreamento do Application Insights

Ao selecionar um rastreamento do Azure Application Insights, a extensão abre a janela Detalhes do Application Insights com as seguintes informações:

• Application Insights – Informações genéricas sobre o log de rastreamento, incluindo o nome da política, a ID de correlação, a ID de rastreamento do Azure Application Insights e o carimbo de data/hora do rastreamento.
• Perfis técnicos – lista de perfis técnicos que aparecem no log de rastreamento.
• Declarações – lista alfabética de declarações que aparecem no log de rastreamento e seus valores. Se uma declaração aparecer no log de rastreamento várias vezes com valores diferentes, um sinal => designará o valor mais recente. É possível revisar essas declarações para determinar se os valores de declaração esperados estão definidos corretamente. Por exemplo, se você tiver uma condição prévia que verifique um valor de declaração, a seção de declarações poderá ajudá-lo a determinar por que um fluxo esperado se comporta de maneira diferente.
• Transformação de declarações – lista de transformações de declarações que aparecem no log de rastreamento. Cada transformação de declarações contém as declarações de entrada, os parâmetros de entrada e as declarações de saída. A seção de transformação de declarações fornece informações sobre os dados enviados e o resultado da transformação de declarações.
• Tokens – lista de tokens que aparecem no log de rastreamento. Os tokens incluem o OAuth federado subjacente e os tokens do provedor de identidade OpenId Connect. O token do provedor de identidade federada fornece detalhes sobre como o provedor de identidade retorna as declarações ao Azure AD B2C para que seja possível mapear as declarações de saída do perfil técnico do provedor de identidade.
• Exceções – lista de exceções ou erros fatais que aparecem no log de rastreamento.
• JSON do Application Insights – os dados brutos retornados pelo Application Insights.

A captura de tela a seguir mostra um exemplo da janela de detalhes do log de rastreamento do Application Insights.

Solucionar problemas de tokens JWT

Para fins de validação e depuração de tokens JWT, é possível decodificar JWTs usando um site como https://jwt.ms. Crie um aplicativo de teste que possa ser redirecionado ao https://jwt.ms para a inspeção de token. Se você ainda não tiver feito isso, registre um aplicativo Web e habilite a concessão implícita de token de ID.

Use Executar agora e https://jwt.ms para testar suas políticas independentemente de seu aplicativo Web ou móvel. Este site funciona como um aplicativo de terceira parte confiável. Ele exibe o conteúdo do JWT (token web JSON) que é gerado pela política do Azure AD B2C.

Solucionar problemas do protocolo SAML

Para ajudar a configurar e depurar a integração com seu provedor de serviços, você pode usar uma extensão do navegador para o protocolo SAML, por exemplo, extensão DevTools SAML para Chrome, SAML-tracer para FireFox ou Ferramentas para Desenvolvedores do IE ou Edge.

A captura de tela a seguir demonstra como a extensão SAML DevTools apresenta a solicitação SAML enviada pelo Azure AD B2C ao provedor de identidade, além da resposta SAML.

Usando essas ferramentas, você pode verificar a integração entre seu aplicativo e o Azure AD B2C. Por exemplo:

• Verifique se a solicitação SAML contém uma assinatura e determine qual algoritmo é usado para entrar na solicitação de autorização.
• Verifique se o Azure AD B2C retorna uma mensagem de erro.
• Verifique se a seção de declaração está criptografada.
• Obtenha o nome das declarações retornadas pelo provedor de identidade.

Para rastrear a troca de mensagens entre o navegador do cliente e o Azure AD B2C, use o Fiddler. Ele pode ajudá-lo a obter uma indicação de onde sua jornada de usuário está falhando nas etapas de orquestração.

Solucionar problemas de validade de política

Depois de concluir o desenvolvimento da política, carregue-a no Azure AD B2C. Talvez haja alguns problemas com a sua política, mas você poderá validá-la antes de carregá-la.

O erro mais comum na configuração de políticas personalizadas é XML com erro de formatação. Um bom editor de XML é praticamente essencial. Ele exibe o XML nativamente, codifica o conteúdo por cor, preenche os termos comuns com antecedência, mantém os elementos XML indexados e pode validar com relação a um esquema XML.

O uso do Visual Studio Code é recomendado. Em seguida, instale uma extensão XML, como o XML Language Support by Red Hat. A extensão XML permite validar o esquema XML antes de carregar o arquivo XML, usando a definição de esquema XSD de política personalizada.

Use a estratégia de associação de arquivo XML para associar o arquivo XML ao XSD adicionando as configurações a seguir ao arquivo settings.json do VS Code. Para fazer isso:

1. No VS Code, selecione Arquivo>Preferências>Configurações. Para obter mais informações, consulte Configurações do espaço de trabalho e do usuário.

2. Procure FileAssociations e, em seguida, em Extensão, selecione o XML.

3. Selecione Editar em settings.json.

   

4. Em settings.json, adicione o código JSON abaixo:

   "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. Salve as alterações.

O exemplo a seguir mostra um erro de validação de XML. Ao passar o mouse sobre o nome do elemento, a extensão lista os elementos esperados.

No caso a seguir, o elemento DisplayName está correto. No entanto, ele está na ordem errada. DisplayName deve anteceder o elemento Protocol. Para corrigir o problema, passe o mouse sobre o elemento DisplayName e o arraste para a ordem de elementos correta.

Políticas de upload e validação de política

A validação do arquivo de política XML é realizada automaticamente durante o upload. A maioria dos erros fazem com que o upload falhe. A validação inclui o arquivo de política que você está carregando. Ela também inclui a cadeia de arquivos à qual o arquivo de upload se refere (o arquivo de política de terceira parte confiável, o arquivo de extensões e o arquivo base).

Dica

O Azure AD B2C executa uma validação adicional para a política de terceira parte confiável. Em caso de problema com sua política, mesmo ao editar apenas a política de extensão, também é uma boa prática carregar a política de terceira parte confiável.

Esta seção contém os erros comuns de validação e as soluções prováveis.

Erro de validação de esquema encontrado... tem um elemento filho '{name}' inválido

Sua política contém um elemento XML inválido ou que é válido, mas que aparenta estar na ordem errada. Para corrigir esse tipo de erro, confira a seção Solucionar problemas de validade de política.

Há uma sequência de chaves duplicada '{number}'

Um percurso ou subpercurso do usuário consiste em uma lista ordenada de etapas de orquestração que são realizadas em sequência. Depois de alterar o percurso, renumere as etapas sequencialmente sem ignorar números inteiros de 1 a N.

Dica

É possível usar a extensão do Azure AD B2C para que o comando (Shift+Ctrl+r) do VS Code possa renumerar todas as etapas de orquestração de percursos e subpercursos do usuário em sua política.

... uma etapa com a ordem "{number}" era esperada, mas ela não foi encontrada...

Verifique o erro anterior.

A ordem da etapa de orquestração "{number}" no percurso do usuário "{name}"... é seguida por uma etapa de seleção de provedor de declarações e deve ser uma troca de declarações, mas é do tipo...

O tipo das etapas de orquestração de ClaimsProviderSelection e CombinedSignInAndSignUp contém uma lista de opções a serem escolhidas por um usuário. Ela deve seguir com o tipo de ClaimsExchange e uma ou mais trocas de declarações.

As etapas de orquestração a seguir causam esse tipo de erro. A segunda etapa de orquestração deve ser do tipo ClaimsExchange, não 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> -->

... etapa {number} com duas trocas de declarações. Deve ser precedida por uma seleção de provedor de declarações para determinar qual troca de declarações pode ser usada

Um tipo de etapa de orquestração ClaimsExchange deve ter um único ClaimsExchange, a menos que a etapa anterior seja do tipo ClaimsProviderSelection ou CombinedSignInAndSignUp. As etapas de orquestração a seguir causam esse tipo de erro. A sexta etapa contém duas trocas de declarações.

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

Para corrigir esse tipo de erro, use duas etapas de orquestração. Cada uma delas com uma troca de declarações.

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

Há uma sequência de chaves duplicada '{name}'

Um percurso tem vários ClaimsExchange com o mesmo Id. As etapas a seguir causam esse tipo de erro. A ID AADUserWrite aparece duas vezes no percurso do usuário.

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

Para corrigir esse tipo de erro, altere a troca de declarações da oitava etapa de orquestração para um nome exclusivo, como 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> -->

... faz uma referência a ClaimType com a ID "{claim name}", mas nem a política nem nenhuma de suas políticas de base contêm esse elemento

Esse tipo de erro ocorre quando sua política faz referência a uma declaração que não existe no esquema de declarações. As declarações devem ser definidas em pelo menos um dos arquivos na política.

Por exemplo, um perfil técnico com a declaração de saída schoolid. No entanto, a declaração de saída schoolId nunca é declarada na política ou em uma política ancestral.

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

Para corrigir esse tipo de erro, verifique se o valor ClaimTypeReferenceId foi digitado incorretamente ou se ele não existe no esquema. Caso a declaração esteja definida na política de extensões, mas também seja usada na política de base. Verifique se a declaração está definida na política em que está sendo usada ou em uma política de nível superior.

Adicionar a declaração ao esquema de declarações resolve esse tipo de erro.

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

...faz uma referência a uma ClaimsTransformation com a ID...

A causa desse erro é semelhante à do erro de declaração. Verifique o erro anterior.

No momento, o usuário está conectado como um usuário do locatário 'yourtenant.onmicrosoft.com'...

Entre com a conta de um locatário diferente da política que será carregada. Por exemplo, você entra com admin@contoso.onmicrosoft.com, mas sua política TenantId está definida para 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>

• Verifique se o valor TenantId nos elementos <TrustFrameworkPolicy\> e <BasePolicy\> corresponde ao locatário de destino do Azure AD B2C.

O tipo de declaração "{name}" é a declaração de saída do perfil técnico da terceira parte confiável, mas ela não é uma declaração de saída em nenhuma das etapas do percurso do usuário...

Em uma política de terceira parte confiável, você adicionou uma declaração de saída, mas ela não é uma declaração de saída em nenhuma das etapas do percurso do usuário. O Azure AD B2C não pode ler o valor da declaração no pacote de declarações.

No exemplo a seguir, a declaração schoolId é uma declaração de saída do perfil técnico da terceira parte confiável, mas não é uma declaração de saída em nenhuma das etapas do percurso do usuário SignUpOrSignIn.

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

Para corrigir esse tipo de erro, certifique-se de que as declarações de saída apareçam em pelo menos uma coleção de declarações de saída de perfil técnico das etapas de orquestração. Se o percurso do usuário não puder gerar a declaração, no perfil técnico da terceira parte confiável, defina um valor padrão, como uma cadeia de caracteres vazia.

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

A cadeia de caracteres de entrada não estava em um formato correto

Você definiu um tipo de valor incorreto para uma declaração de outro tipo. Por exemplo, uma declaração de inteiro é definida.

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

Em seguida, você tenta definir um valor de cadeia de caracteres:

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

Para corrigir esse tipo de erro, certifique-se de definir o valor correto, como DefaultValue="0".

O locatário "{name}" já tem uma política com a ID "{name}". Não é possível armazenar outra política com a mesma ID

Você tenta carregar uma política em seu locatário, mas outra com o mesmo nome já foi carregada nele.

Para corrigir esse tipo de erro, ao carregar a política, marque a caixa de seleção Substituir a política personalizada se ela já existir.

Próximas etapas

• Saiba como coletar logs do Azure Active Directory B2C com o Application Insights.