Partilhar via

Solucionar problemas de provisionamento de aplicativos locais

  • Artigo

Solucionar problemas de conexão de teste

Depois de configurar o agente de provisionamento e o host ECMA (Extensible Connectivity), é hora de testar a conectividade do serviço de provisionamento Microsoft Entra com o agente de provisionamento, o host ECMA e o aplicativo. Para executar esse teste de ponta a ponta, selecione Testar conexão no aplicativo no portal do Azure. Certifique-se de aguardar 10 a 20 minutos depois de atribuir um agente inicial ou alterar o agente antes de testar a conexão. Se, após esse período, a conexão de teste falhar, tente as seguintes etapas de solução de problemas:

  1. Verifique se o agente e o host ECMA estão em execução:

    1. No servidor com o agente instalado, abra Serviços indo para Iniciar>Executar>Services.msc.

    2. Em Serviços, verifique se os serviços Microsoft Entra Connect Provisioning Agent e Microsoft ECMA2Host estão presentes e se seu status é Em Execução.

      Screenshot that shows that the ECMA service is running.

  2. Verifique se o serviço ECMA Connector Host está respondendo às solicitações.

    1. No servidor com o agente instalado, inicie o PowerShell.
    2. Mude para a pasta onde o host ECMA foi instalado, como C:\Program Files\Microsoft ECMA2Host.
    3. Mude para o subdiretório Troubleshooting.
    4. Execute o script TestECMA2HostConnection.ps1 nesse diretório. Forneça como argumentos o nome do conector e o token secreto quando solicitado. 
      PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1
Supply values for the following parameters:
ConnectorName: CORPDB1
SecretToken: ************
    5. Esse script envia uma solicitação SCIM GET ou POST para validar se o ECMA Connector Host está operando e respondendo às solicitações. Se a saída não mostrar que uma conexão HTTP foi bem-sucedida, verifique se o serviço está em execução e se o token secreto correto foi fornecido.

  3. Certifique-se de que o agente está ativo acessando seu aplicativo no portal do Azure, selecionando conectividade de administrador, selecionando a lista suspensa de agente e garantindo que seu agente esteja ativo.

  4. Verifique se o token secreto fornecido é o mesmo que o token secreto local. Vá para local, forneça o token secreto novamente e copie-o para o portal do Azure.

  5. Certifique-se de ter atribuído um ou mais agentes ao aplicativo no portal do Azure.

  6. Depois de atribuir um agente, você precisa aguardar de 10 a 20 minutos para que o registro seja concluído. O teste de conectividade não funcionará até que o registro seja concluído.

  7. Certifique-se de que está a utilizar um certificado válido que não expirou. Vá para a guia Configurações do host ECMA para exibir a data de expiração do certificado. Se o certificado expirou, clique Generate certificate para gerar um novo certificado.

  8. Reinicie o agente de provisionamento indo para a barra de tarefas em sua VM procurando o agente de provisionamento do Microsoft Entra Connect. Clique com o botão direito do rato em Parar e, em seguida, selecione Iniciar.

  9. Se você continuar a ver The ECMA host is currently importing data from the target application mesmo depois de reiniciar o ECMA Connector Host e o agente de provisionamento, e aguardar a conclusão da importação inicial, talvez seja necessário cancelar e começar de novo a configurar o provisionamento para o aplicativo no portal do Azure.

  10. Ao fornecer a URL do locatário no portal do Azure, verifique se ela segue o padrão a seguir. Pode substituir localhost pelo seu nome de anfitrião, mas não é necessário. Substitua connectorName pelo nome do conector especificado no host ECMA. A mensagem de erro 'recurso inválido' geralmente indica que o URL não segue o formato esperado.

    https://localhost:8585/ecma2host_connectorName/scim

  11. Navegue até a seguinte pasta para revisar os logs do agente de provisoning: C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace

    1. Se você vir o seguinte erro, adicione a conta de serviço "NT SERVICE\AADConnectProvisioningAgent" ao grupo local chamado "Usuários de log de desempenho". Isso elimina o erro de exceção "Não é possível inicializar o coletor de métricas", permitindo que a conta acesse a chave do Registro desejada: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
Unable to initialize metrics collector, exception: 'System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
  1. Ao configurar o host ECMA, certifique-se de fornecer um certificado com uma entidade que corresponda ao nome do host do seu servidor Windows. O certificado gerado pelo host ECMA fará isso automaticamente, mas só deve ser usado para fins de teste.
Error code: SystemForCrossDomainIdentityManagementCredentialValidationUnavailable

Details: We received this unexpected response from your application: Received response from Web resource. Resource: https://localhost/Users?filter=PLACEHOLDER+eq+"8646d011-1693-4cd3-9ee6-0d7482ca2219" Operation: GET Response Status Code: InternalServerError Response Headers: Response Content: An error occurred while sending the request. Please check the service and try again.

Não é possível configurar o host ECMA, exibir logs no Visualizador de Eventos ou iniciar o serviço de host ECMA

Para resolver os seguintes problemas, execute o assistente de configuração de host ECMA como administrador:

  • Recebo um erro quando abro o assistente de host ECMA.

    Screenshot that shows an ECMA wizard error.

  • Posso configurar o assistente de host ECMA, mas não consigo ver os logs de host ECMA. Nesse caso, você precisa abrir o assistente de configuração do ECMA Host como administrador e configurar um conector de ponta a ponta. Esta etapa pode ser simplificada exportando um conector existente e importando-o novamente.

    Screenshot that shows host logs.

  • Posso configurar o assistente de host ECMA, mas não consigo iniciar o serviço de host ECMA.

    Screenshot that shows the host service.

Ativar o registo detalhado

Por padrão, switchValue para o ECMA Connector Host é definido como Verbose. Essa configuração emitirá um registro detalhado que ajudará você a solucionar problemas. Você pode alterar a verbosidade para Error se quiser limitar o número de logs emitidos apenas a erros. Wen usando o conector SQL sem autenticação integrada do Windows, recomendamos definir o switchValue para Error , pois ele garantirá que a cadeia de conexão não seja emitida nos logs. Para alterar a verbosidade para erro, atualize o switchValue para "Erro" em ambos os lugares, conforme mostrado abaixo.

O local do arquivo para o log detalhado do serviço é C:\Program Files\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.config.

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <startup>  
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> 
    </startup> 
    <appSettings> 
      <add key="Debug" value="true" /> 
    </appSettings> 
    <system.diagnostics> 
      <sources> 
    <source name="ConnectorsLog" switchValue="Error"> 
          <listeners> 
            <add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack"> 
              <filter type=""/> 
            </add> 
          </listeners> 
        </source> 
        <!-- Choose one of the following switchTrace:  Off, Error, Warning, Information, Verbose --> 
        <source name="ECMA2Host" switchValue="Error"> 
          <listeners>  
            <add initializeData="ECMA2Host" type="System.Diagnos

O local do arquivo para o log do assistente é C:\Program Files\Microsoft ECMA2Host\Wizard\Microsoft.ECMA2Host.ConfigWizard.exe.config.

      <source name="ConnectorsLog" switchValue="Error"> 
        <listeners> 
          <add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack"> 
            <filter type=""/> 
          </add> 
        </listeners> 
      </source> 
      <!-- Choose one of the following switchTrace:  Off, Error, Warning, Information, Verbose --> 
      <source name="ECMA2Host" switchValue="Error"> 
        <listeners> 
          <add initializeData="ECMA2Host" type="System.Diagnostics.EventLogTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ECMA2HostListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" />

Consultar o cache do host ECMA

O Host ECMA tem um cache de usuários em seu aplicativo que é atualizado de acordo com o cronograma especificado na página de propriedades do assistente de Host ECMA. Para consultar o cache, execute as etapas abaixo:

  1. Defina o sinalizador Depurar como true.

    Lembre-se de que definir o sinalizador de depuração para true desativar a autenticação no host ECMA. Você precisará configurá-lo de volta e false reiniciar o serviço ECMA Host assim que terminar de consultar o cache.

    O local do arquivo para o registro detalhado do serviço é C:\Program Files\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.config.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <startup>  
       <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> 
   </startup> 
   <appSettings> 
     <add key="Debug" value="true" /> 
   </appSettings>

  2. Reinicie o Microsoft ECMA2Host serviço.

  3. Aguarde até que o host ECMA se conecte aos sistemas de destino e releia seu cache de cada um dos sistemas conectados. Se houver muitos usuários nesses sistemas conectados, esse processo de importação pode levar vários minutos.

  4. Consulte este ponto de extremidade a partir do servidor em que o Host ECMA está instalado, substituindo {connector name} pelo nome do seu conector, especificado na página de propriedades do Host ECMA: https://localhost:8585/ecma2host_{connectorName}/scim/cache.

    1. No servidor com o agente instalado, inicie o PowerShell.
    2. Mude para a pasta onde o host ECMA foi instalado, como C:\Program Files\Microsoft ECMA2Host.
    3. Mude para o subdiretório Troubleshooting.
    4. Execute o script TestECMA2HostConnection.ps1 nesse diretório e forneça como argumentos o nome do conector e o ObjectTypePath valor cache. Quando solicitado, digite o token secreto configurado para esse conector. 
      PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1 -ConnectorName CORPDB1 -ObjectTypePath cache
Supply values for the following parameters:
SecretToken: ************
    5. Esse script envia uma solicitação SCIM GET para validar se o ECMA Connector Host está operando e respondendo às solicitações. Se a saída não mostrar que uma conexão HTTP foi bem-sucedida, verifique se o serviço está em execução e se o token secreto correto foi fornecido.

  5. Defina o sinalizador Debug de volta ou false remova a configuração assim que terminar de consultar o cache.

  6. Reinicie o Microsoft ECMA2Host serviço.

O atributo de destino está ausente

O serviço de provisionamento descobre automaticamente atributos em seu aplicativo de destino. Se você vir que um atributo de destino está faltando na lista de atributos de destino no portal do Azure, execute a seguinte etapa de solução de problemas:

  1. Revise a página Selecionar Atributos da configuração do host ECMA para verificar se o atributo foi selecionado, para que seja exposto ao portal do Azure.
  2. Verifique se o serviço de host ECMA está em execução.
  3. Depois de atribuir o(s) agente(s) ao aplicativo empresarial, concluir a etapa de conexão de teste e salvar as credenciais de administrador, atualize o navegador. Isso forçará o serviço de provisionamento a fazer uma solicitação /schemas e descobrir os atributos de destino.
  4. Revise os logs do host ECMA para verificar se uma solicitação /schemas foi feita e revise os atributos na resposta. Essas informações serão valiosas para o suporte na solução do problema.

Coletar logs do Visualizador de Eventos como um arquivo zip

Você pode usar um script incluído para capturar os logs de eventos em um arquivo zip e exportá-los.

  1. No servidor com o agente instalado, clique com o botão direito do mouse em PowerShell no menu Iniciar e selecione .Run as administrator
  2. Mude para a pasta onde o host ECMA foi instalado, como C:\Program Files\Microsoft ECMA2Host.
  3. Mude para o subdiretório Troubleshooting.
  4. Execute o script CollectTroubleshootingInfo.ps1 nesse diretório.
  5. O script criará um arquivo ZIP nesse diretório contendo os logs de eventos.

Rever eventos no Visualizador de Eventos

Depois que o mapeamento de esquema do ECMA Connector Host tiver sido configurado, inicie o serviço para que ele escute as conexões de entrada. Em seguida, monitore as solicitações recebidas.

  1. Selecione o menu Iniciar, insira o visualizador de eventos e selecione Visualizador de eventos.
  2. No Visualizador de Eventos, expanda Logs de Aplicativos e Serviços e selecione Logs do Microsoft ECMA2Host.
  3. À medida que as alterações são recebidas pelo host do conector, os eventos serão gravados no log do aplicativo.

Erros comuns

Error Resolução
Não foi possível carregar o arquivo ou assembly 'file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\Cache\8b514472-c18a-4641-9a44-732c296534e8\Microsoft.IAM.Connector.GenericSql.dll' ou uma de suas dependências. O acesso é negado. Verifique se a conta de serviço de rede tem permissões de 'controle total' sobre a pasta de cache.
Estilo LDAP inválido do DN do objeto. DN: username@domain.com" ou Target Site: ValidByLdapStyle Verifique se a caixa de seleção 'DN é âncora' não está marcada na página 'conectividade' do host ECMA. Verifique se a caixa de seleção 'gerado automaticamente' está selecionada na página 'tipos de objeto' do host ECMA. Para obter mais informações, consulte Sobre atributos de âncora e nomes distintos.
ExportErrorCustomContinueRun. objectClass: número de valor inválido por sintaxe Certifique-se de que o mapeamento do atributo de provisionamento para o objectClass atributo inclua apenas nomes de classes de objeto reconhecidas pelo servidor de diretório.

Compreender as solicitações SCIM recebidas

As solicitações feitas pelo Microsoft Entra ID ao agente de provisionamento e ao host do conector usam o protocolo SCIM. As solicitações feitas do host para aplicativos usam o protocolo suportado pelo aplicativo. As solicitações do host para o agente para o Microsoft Entra ID dependem do SCIM. Você pode saber mais sobre a implementação SCIM em Tutorial: Desenvolver e planejar o provisionamento para um ponto de extremidade SCIM no Microsoft Entra ID.

O serviço de provisionamento do Microsoft Entra geralmente faz uma chamada get-user para verificar se há um usuário fictício em três situações: no início de cada ciclo de provisionamento, antes de executar o provisionamento sob demanda e quando a conexão de teste é selecionada. Essa verificação garante que o ponto de extremidade de destino esteja disponível e retorne respostas compatíveis com SCIM para o serviço de provisionamento do Microsoft Entra.

Como soluciono problemas do agente de provisionamento?

Você pode enfrentar os seguintes cenários de erro.

Falha ao iniciar o agente

Poderá receber uma mensagem de erro que indique:

"Falha ao iniciar o serviço 'Microsoft Entra Connect Provisioning Agent'. Verifique se você tem privilégios suficientes para iniciar os serviços do sistema."

Esse problema geralmente é causado por uma diretiva de grupo que impediu que as permissões fossem aplicadas à conta de entrada do serviço NT local criada pelo instalador (NT SERVICE\AADConnectProvisioningAgent). Estas permissões são necessárias para iniciar o serviço.

Para resolver esse problema:

  1. Entre no servidor com uma conta de administrador.
  2. Abra Serviços navegando até ele ou indo para Start>Run>Services.msc.
  3. Em Serviços, clique duas vezes em Microsoft Entra Connect Provisioning Agent.
  4. No separador Iniciar sessão, altere Esta conta para um administrador de domínio. Em seguida, reinicie o serviço.

Este teste verifica se os seus agentes podem comunicar com o Azure através da porta 443. Abra um navegador e vá para a URL anterior do servidor onde o agente está instalado.

O tempo limite do agente ou o certificado é inválido

Poderá receber a seguinte mensagem de erro quando tentar registar o agente.

Screenshot that shows that the agent timed out.

Normalmente, este problema é causado pelo facto de o agente não conseguir ligar ao Serviço de Identidade Híbrido e requer a configuração de um proxy HTTP. Para resolver este problema, configure um proxy de saída.

O agente de provisionamento oferece suporte ao uso de um proxy de saída. Você pode configurá-lo editando o arquivo de configuração do agente C:\Arquivos de Programas\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config. Adicione as seguintes linhas a ele, no final do arquivo, logo antes da tag de fechamento </configuration> . Substitua as variáveis [proxy-server] pelo [proxy-port] nome do servidor proxy e pelos valores da porta.

    <system.net>
        <defaultProxy enabled="true" useDefaultCredentials="true">
            <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
            />
        </defaultProxy>
    </system.net>

O registro do agente falha com erro de segurança

Você pode receber uma mensagem de erro ao instalar o agente de provisionamento de nuvem.

Esse problema geralmente é causado pelo agente não conseguir executar os scripts de registro do PowerShell devido às políticas de execução do PowerShell local.

Para resolver esse problema, altere as políticas de execução do PowerShell no servidor. Você precisa ter as políticas de Máquina e Usuário definidas como Undefined ou RemoteSigned. Se eles estiverem definidos como Sem restrições, você verá esse erro. Para obter mais informações, consulte Políticas de execução do PowerShell.

Ficheiros de registo

Por predefinição, o agente emite mensagens de erro mínimas e informações de rastreio de pilha. Você pode encontrar logs de rastreamento na pasta C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace.

Para reunir mais informações para solucionar problemas relacionados ao agente:

  1. Instale o AADCloudSyncTools módulo PowerShell conforme descrito no AADCloudSyncTools módulo PowerShell para sincronização na nuvem do Microsoft Entra Connect.

  2. Use o Export-AADCloudSyncToolsLogs cmdlet do PowerShell para capturar as informações. Use as opções a seguir para ajustar sua coleta de dados. Utilizar:

    • SkipVerboseTrace para exportar apenas logs atuais sem capturar logs detalhados (padrão = false).
    • TracingDurationMins para especificar uma duração de captura diferente (padrão = 3 minutos).
    • OutputPath para especificar um caminho de saída diferente (padrão = documentos do usuário).

Usando o Microsoft Entra ID, você pode monitorar o serviço de provisionamento na nuvem e coletar logs no local. O serviço de provisionamento emite logs para cada usuário que foi avaliado como parte do processo de sincronização. Esses logs podem ser consumidos por meio da interface do usuário do portal do Azure, APIs e análise de log. O host ECMA também gera logs no local. Ele mostra cada solicitação de provisionamento recebida e a resposta enviada para o Microsoft Entra ID.

Falha na instalação do agente

  • O erro System.ComponentModel.Win32Exception: The specified service already exists indica que o host ECMA anterior foi desinstalado sem êxito. Desinstale o aplicativo host. Vá para arquivos de programa e remova a pasta host ECMA. Talvez você queira armazenar o arquivo de configuração para backup.

  • O erro a seguir indica que um pré-requisito não foi atendido. Certifique-se de ter o .NET 4.7.1 instalado.

      Method Name : <>c__DisplayClass0_1 : 
  RegisterNotLoadedAssemblies Error during load assembly: System.Management.Automation.resources.dll
  --------- Outer Exception Data ---------
  Message: Could not load file or assembly 'file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\System.Management.Automation.resources.dll' or one of its dependencies. The system cannot find the file specified.

Estou recebendo um erro DN de estilo LDAP inválido ao tentar configurar o ECMA Connector Host com SQL

Por padrão, o conector SQL genérico espera que o DN seja preenchido usando o estilo LDAP (quando o atributo 'DN é âncora' é deixado desmarcado na primeira página de conectividade). Na mensagem Invalid LDAP style DN de erro ou Target Site: ValidByLdapStyle, você pode ver que o campo DN contém um nome principal do usuário (UPN), em vez de um DN estilo LDAP que o conector espera.

Para resolver essa mensagem de erro, verifique se Autogenerated está selecionado na página de tipos de objeto quando você configura o conector.

Para obter mais informações, consulte Sobre atributos de âncora e nomes distintos.

Próximos passos