Depuração do Credentials Proxy do Orchestrator

Logs

Por padrão, o Credentials Proxy do Orchestrator registra todas as exceções e as primeiras informações de inicialização e desligamento.

Para verificar se o Credentials Proxy está realmente fazendo o registro de 200 solicitações, inicie o Credentials Proxy do Orchestrator no servidor local, acesse o Swagger e execute o ponto de extremidade de Integridade (não autenticado): api/v1/Health. As solicitações agora devem ser registradas.

Observação: após cada alteração no arquivo appsettings, você precisa reiniciar o Credentials Proxy.

Se você seguir essas etapas e nenhum log adicional além de inicialização e desligamento estiver disponível, isso significa que nenhuma solicitação estará chegando ao Credentials Proxy do Orchestrator. Isso é mais provavelmente causado por um problema de infraestrutura ou rede nas máquinas do Orchestrator Cloud Robot e Credentials Proxy do Orchestrator.

Visualizador de eventos

Todos os logs devem aparecer no Visualizador de Eventos do Windows para Credentials Proxy e Orchestrator versões 2.0.0 e superiores.

Alteração do destino do arquivo de log

Para alterar o caminho do arquivo de log, abra o arquivo appsettings.production.json e use o código a seguir. Você pode substituir C:/dev/logs pelo caminho desejado:

  "NLog": {
    "throwConfigExceptions": true,
    "targets": {
      "logfile": {
        "type": "File",
        "maxArchiveFiles": 180,
        "fileName": "C:/dev/logs/nlog-${shortdate}.log",
        "layout": "${longdate} ${logger} ${message}${onexception:${newline}${exception:maxInnerExceptionLevel=10:format=shortType,message,stacktrace:separator=*:innerExceptionSeparator=
	}}"
      }
    },
    "rules": [
      {
        "logger": "*",
        "minLevel": "Information",
        "writeTo": "logconsole,logfile,eventLog"
      }
    ]
  }

Logs adicionais

Observação: esse procedimento deve ser usado apenas para depuração.Quando concluído, reverta essas alterações, pois isso produzirá excesso de logs.

Os níveis de registro padrão são semelhantes aos seguintes:

  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },

Se você quiser obter mais logs, por exemplo, para ver todas as solicitações que chegam ao proxy, você precisa editar o arquivo appsettings.Production.json e adicionar o seguinte:

  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Information",
      "Microsoft.AspNetCore": "Information",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
    }
  }

Se o Information não for suficiente e você quiser mais ou menos, você pode usar os valores LogLevels de .Net. Para obter mais informações, consulte a documentação da Microsoft.O arquivo appsettings.json deve ser semelhante ao seguinte:

  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Information",
      "Microsoft.AspNetCore": "Information",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
    }
  }

Reinicie o Credentials Proxy do Orchestrator após alterar o arquivo appsettings.

Teste com o InMemoryStore

Se você estiver encontrando problemas de depuração e quiser verificar com um tipo de armazenamento de credenciais diferente, você pode usar o Credentials Proxy do Orchestrator tipo InMemorySecureStore.

Observação: use esse procedimento apenas para fins de teste.

Para habilitar o tipo InMemorySecureStore, abra o arquivo appsettings.production.json, acesse a seção AppSettings e adicione o parâmetro "UseInMemorySecureStore": "true".

Para habilitá-lo para proxies Desconectados, inclua o seguinte na seção SecureStoreConfigurations também:

{
  "Key": "InMemoryKey1", // can be any value
  "Type": "InMemorySecureStore",
  "Context": {
  }
}

O proxy conectado não pôde se conectar

Ao configurar uma conexão do Credentials Proxy do Orchestrator e tentar vinculá-la ao Orchestrator, você pode encontrar a seguinte mensagem de erro:

Request to the Credentials Proxy's unauthenticated health endpoint failed.

Durante o processo de conexão, o Orchestrator executa uma solicitação GET simples ao ponto de extremidade /api/v1/Health do proxy.

A finalidade dessa solicitação é verificar se o proxy é acessível a partir do ambiente de cloud do Orchestrator. Se essa solicitação falhar, isso indica que o Orchestrator não pode acessar o proxy, e a verificação de conexão não será aprovada.

Problemas comuns

• O Credentials Proxy do Orchestrator não é iniciado:

  • Acesse o Servidor onde o Credentials Proxy do Orchestrator está instalado.

  • No IIS, verifique se o aplicativo Credentials Proxy está em execução.

  • No mesmo servidor, abra um navegador e verifique se o URL de Credentials Proxy é acessível localmente.

• A conexão não tem um certificado HTTPS/SSL válido. Toda a comunicação entre o Orchestrator e o OCP deve ser segura.

  • Certifique-se de que seu Credentials Proxy usa um certificado HTTPS/SSL válido.

  • (Opcional) Se um balanceador de carga for configurado na frente do Credentials Proxy do Orchestrator, confirme se ele também usa uma conexão HTTPS segura.

• O Credentials Proxy do Orchestrator é bloqueado por trás de um firewall, VPN ou restrição de rede semelhante. Se o Credentials Proxy não estiver acessível a partir do Orchestrator, verifique sua configuração de rede.
  • Certifique-se de que os IPs de saída do Orchestrator estejam devidamente na lista de permissões. Consulte a página para obter mais informações.
    Observação: se sua organização tiver vários tenants, eles podem ser hospedados em regiões diferentes e usar endereços IP diferentes. Verifique cada tenant novamente.
• Problema com o ponto de extremidade não autenticado devido à hora incorreta do servidor.
  • Se o ponto de extremidade não autenticado falhar, é possível que a hora do servidor não esteja configurada corretamente. Quando o relógio do sistema está errado, o servidor pode interpretar os tokens JWT como inválidos.

Etapas para investigar

1. Verifique no IIS se o Credentials Proxy do Orchestrator está em execução.
2. Verifique no navegador se o URL de credentials proxy está acessível e é carregado corretamente.
3. Verifique no navegador se o URL de Credentials Proxy é seguro.
4. Na máquina credentials proxy, aumente o nível de registro para Informação para solução de problemas. Lembre-se de reverter essa alteração após concluir a investigação.
5. Teste o ponto de extremidade integridade localmente. Na máquina de credentials proxy, abra o Swagger ou use uma ferramenta como o Postman para fazer uma solicitação para:

   https://{yourCredentialsProxyUrl}/api/v1/Health

   Uma resposta bem-sucedida indica que o proxy está acessível e operacional localmente.

6. Teste o acesso dentro da VPN. De outra máquina dentro da mesma VPN (por exemplo, o notebook de um cliente ou a máquina do robô de um cliente), verifique se o URL do Credentials Proxy está acessível. Faça uma solicitação para o mesmo ponto de extremidade /api/v1/Health:

   • Se funcionar, o Credentials Proxy é acessível de dentro da VPN.

   • Se não funcionar, o cliente deve resolver o problema de rede interna ou de roteamento.

7. Teste de acessibilidade pública.
8. Em uma máquina que não está dentro da VPN, consulte o ponto de extremidade /api/v1/Health:

   • Se funcionar, o Credentials Proxy pode ser acessado de fora da VPN.

   • Se não funcionar, o cliente deve resolver o problema de rede interna ou de roteamento.

9. Teste a conexão do Orchestrator cloud. Crie um novo Credentials Proxy vinculado ao mesmo URL de proxy:

   • Se a criação for bem-sucedida, você pode excluir a conexão.

   • Se falhar, algo ainda está bloqueando a comunicação entre o Orchestrator e o Credentials Proxy.

     Observação: neste ponto, o Credentials Proxy deve ser acessível publicamente, sem restrições de firewall ou lista de permissões de IP.
10. Recupere a lista de endereços IP de tenant do Orchestrator.

11. Adicione os IPs à lista de permissões para acesso ao Credentials Proxy.

12. De uma máquina fora da VPN, teste o ponto de extremidade /api/v1/Health novamente.Isso não deve funcionar, já que o IP não é adicionado à lista de permissões.
13. No Orchestrator Cloud, tente criar um Credentials Proxy novamente:
    • Se todas as etapas tiverem sido concluídas corretamente, agora deve ser bem-sucedido.
    • Se ainda falhar, pode haver um problema com as regras de firewall ou VPN impedindo a comunicação entre o Orchestrator e o Credentials Proxy.
14. Se o problema persistir, repita as etapas acima cuidadosamente e verifique cada ponto de configuração.
15. Após o problema ser resolvido, reverta o nível de log na máquina credentials proxy para sua configuração original.

O proxy desconectado não será iniciado ou registrado

O credentials proxy desconectado executa uma etapa de validação durante a inicialização para garantir que ele possa atender corretamente as solicitações de clientes. Como parte desse processo, o proxy valida cada configuração definida em AppSettings:SecureStoreConfigurations. A lógica de validação específica aplicada depende do tipo de armazenamento de credenciais configurado.

Em certos casos, a causa raiz da falha do proxy ao iniciar pode ocorrer tão cedo no processo de inicialização que o aplicativo não chega ao ponto de gerar ou gravar quaisquer eventos de log.

Possíveis causas para que o app não inicie

Vários problemas podem impedir que o aplicativo Credentials Proxy seja iniciado. Abaixo estão causas comuns e como identificá-las.

• Pool de aplicativos IIS não iniciado (Windows). Se o proxy estiver hospedado no IIS, verifique se o pool de aplicativos associado a ele está em execução. Você pode verificar isso no IIS Manager na seção Pools de Aplicativos.
• Configuração inválida em appsettings.Production.json. Um arquivo de configuração inválido ou incompleto pode fazer com que o proxy falhe durante a inicialização. Consulte os exemplos na seção Exemplos de configuração para obter mais detalhes.
• Configuração inválida em AppSettings:SecureStoreConfigurations. A seção SecureStoreConfigurations define como o proxy se conecta e valida armazenamentos de credenciais. Se qualquer uma dessas entradas estiver malformada ou incompleta, o aplicativo não será iniciado.
  • Parâmetros inválidos na configuração. Certifique-se de que todos os parâmetros de configuração correspondam ao tipo de armazenamento de credenciais que você está usando. O uso de parâmetros ou chaves incorretos pode causar falha na validação de inicialização.
  • Não é possível acessar o cofre. Se o armazenamento de credenciais configurado depender de um cofre externo (por exemplo, CyberArk, BeyondTrust ou outros), a inicialização pode falhar se o proxy não puder acessar ou autenticar com ele.
• Outros problemas relacionados à infraestrutura.

Depuração

Ao depurar o credentials proxy, o objetivo é eliminar o maior número de variáveis possível antes de testar configurações complexas.

• Comece usando uma configuração mínima com o tipo InMemorySecureStore. Isso permite que você confirme que o proxy pode ser iniciado com sucesso antes de introduzir dependências externas.
  • Adicione o parâmetro "UseInMemorySecureStore": "true", em AppSettings.
  • Adicione o seguinte em AppSettings:SecureStoreConfigurations:

    "SecureStoreConfigurations": [
      {
        "Key": "InMemoryKey1",
        "Type": "InMemorySecureStore",
        "Context": {  }
      }
    ]

  • O proxy não deve mais ter problemas relacionados à configuração. Se mesmo assim não iniciar, a causa provavelmente está relacionada à infraestrutura.
• Após confirmar que o proxy inicia com sucesso usando a configuração em memória, substitua-o por sua configuração real de armazenamento de credenciais (por exemplo, CyberArk, BeyondTrust e outros).
  • Atualizar a seção SecureStoreConfigurations com base em seu ambiente e tipo de armazenamento.

    Se o aplicativo não for iniciado, você deve localizar logs em:

    • O Visualizador de eventos do Windows.

    • O diretório de logs configurado do proxy.

  • Se o aplicativo não iniciar e nenhum log for gerado, o problema provavelmente está relacionado à infraestrutura ou permissões em seu ambiente.

    Para ajudar na depuração nesses casos, você pode desabilitar temporariamente a validação do armazenamento seguro adicionando este parâmetro em AppSettings:

    "SkipValidateSecureStoreConfigurations": true
    

    Observação: esse parâmetro deve ser usado apenas para fins de depuração.A validação de inicialização existe para garantir que sua configuração de proxy esteja correta e segura.