Débogage d'Orchestrator Credentials Proxy

Journaux (Logs)

Par défaut, Orchestrator Credentials Proxy enregistre toutes les exceptions et les informations de démarrage et d'arrêt initiaux.

Pour vérifier si Credentials Proxy journalise vraiment 200 demandes, démarrez Orchestrator Credentials Proxy sur le serveur local, accédez à Swagger et exécutez le point de terminaison Santé (non authentifié) : api/v1/Health.Les demandes doivent désormais être journalisées.

Remarque: Après chaque modification du appsettingsfichier, vous devez redémarrer Credentials Proxy.

Si vous suivez ces étapes et qu'aucun journal supplémentaire en dehors du démarrage et de l'arrêt n'est disponible, cela signifie qu'aucune demande n'atteint Orchestrator Credentials Proxy. Cela est très probablement causé par un problème d'infrastructure ou de mise en réseau des machines Orchestrator Cloud robot et Orchestrator Credentials Proxy.

Visionneuse d'événements

Tous les journaux doivent apparaître dans le visualiseur d'événements Windows pour Orchestrator Credentials Proxy versions 2.0.0 et ultérieures.

Modification de la destination du fichier journal

Pour modifier le chemin du fichier journal, ouvrez le fichier appsettings.production.jsonet utilisez le code suivant. Vous pouvez remplacer C:/dev/logspar le chemin souhaité :

  "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"
      }
    ]
  }

Journaux supplémentaires

Remarque: Cette procédure doit uniquement être utilisée pour le débogage. Une fois que vous avez terminé, inversez ces modifications, car cela produira des journaux excessifs.

Les niveaux de journalisation par défaut sont similaires à ce qui suit :

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

Si vous souhaitez obtenir plus de journaux, par exemple pour voir toutes les demandes arrivant au proxy, vous devez modifier le fichier appsettings.Production.jsonet ajouter ce qui suit :

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

Si le Information ne suffit pas et que vous souhaitez plus ou moins, vous pouvez utiliser les valeurs de LogLevels.Net. Pour de plus amples informations, vérifiez la documentation de Microsoft.Le fichier doit ressembler à ce qui suit appsettings.json:

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

Redémarrez Orchestrator Credentials Proxy après avoir modifié le fichierappsettings.

Tester avec InMemoryStore

Si vous rencontrez des problèmes de débogage et que vous souhaitez vérifier avec un autre type de magasin d'informations d'identification, vous pouvez utiliser le type Orchestrator Credentials ProxyInMemorySecureStore.

Remarque: Utilisez cette procédure uniquement à des fins de test.

Pour activer le InMemorySecureStoretype, ouvrez le fichier, accédez à la section appsettings.production.jsonAppSettings et ajoutez le paramètre"UseInMemorySecureStore": "true".

Pour l'activer pour les proxies déconnectés, incluez également les éléments suivants dans la SecureStoreConfigurations section:

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

Le proxy connecté n'a pas pu se connecter

Lors de la configuration d'une connexion Orchestrator Credentials Proxy et de la tentative de la lier à Orchestrator, vous pourriez rencontrer le message d'erreur suivant :

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

Pendant le processus de connexion, Orchestrator effectue une simple demande GET au point de terminaison du proxy/api/v1/Health.

La finalité de cette demande est de vérifier que le proxy est accessible depuis l'environnement Cloud Orchestrator.Si cette demande échoue, cela indique qu'Orchestrator ne peut pas accéder au proxy et que la vérification de la connexion ne réussira pas.

Problèmes couramment rencontrés

• Orchestrator Credentials Proxy n'est pas démarré:

  • Accédez au serveur où Orchestrator Credentials Proxy est installé.

  • Dans IIS, vérifiez que l'application Credentials Proxy est en cours d'exécution.

  • Sur le même serveur, ouvrez un navigateur et vérifiez que l'URL de Credentials Proxy est accessible localement.

• La connexion ne dispose pas d'un certificat HTTPS/SSL valide.Toutes les communications entre Orchestrator et OCP doivent être sécurisées.

  • Assurez-vous que votre Credentials Proxy utilise un certificat HTTPS/SSL valide.

  • (Facultatif) Si un équilibreur de charge est configuré devant Orchestrator Credentials Proxy, confirmez qu'il utilise également une connexion HTTPS sécurisée.

• Orchestrator Credentials Proxy est bloqué derrière un pare-feu, un VPN ou une restriction réseau similaire. Si le Credentials Proxy n'est pas accessible depuis Orchestrator, vérifiez votre configuration réseau.
  • Assurez-vous que les IP sortantes d'Orchestrator figurent correctement sur la liste blanche.Vérifiez la page Adresses IP sortantes d'Orchestrator pour de plus amples informations.
    Remarque : Si votre organisation compte plusieurs locataires, ils pourraient être hébergés dans différentes régions et utiliser des adresses IP différentes.Vérifiez deux fois pour chaque locataire.
• Problème de point de terminaison non authentifié en raison d'une heure du serveur incorrecte.
  • Si le point de terminaison non authentifié échoue, il est possible que l'heure du serveur ne soit pas correctement définie.Lorsque l'horloge système est inexacte, le serveur peut interpréter les jetons JWT comme non valides.

Étapes de l'enquête

1. Vérifiez dans IIS que Orchestrator Credentials Proxy est en cours d'exécution.
2. Vérifiez dans le navigateur que l'URL du proxy Credentials Proxy est accessible et se charge correctement.
3. Vérifiez dans le navigateur que l'URL de Credentials Proxy est sécurisée.
4. Sur la machine Credentials Proxy, augmentez le niveau de journalisation à Information pour la résolution des problèmes.N'oubliez pas d'inverser cette modification après avoir terminé l'enquête.
5. Testez localement le point de terminaison de santé.Sur la machine Credentials Proxy, ouvrez Swagger ou utilisez un outil tel que Postman pour effectuer une demande à :

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

   Une réponse réussie indique que le proxy est accessible et opérationnel localement.

6. Testez l'accès dans le VPN. Depuis une autre machine au sein du même VPN (par exemple, l'ordinateur portable d'un client ou la machine robot d'un client), vérifiez que l'URL de Credentials Proxy est accessible.Effectuez une demande au même point de terminaison /api/v1/Health :

   • Si cela fonctionne, le Credentials Proxy est accessible depuis l'intérieur du VPN.

   • Si ce n'est pas le cas, le client doit résoudre le problème de réseau interne ou de routage.

7. Testez l'accessibilité publique.
8. Sur une machine qui ne se trouve pas à l'intérieur du VPN, vérifiez le /api/v1/Health point de terminaison :

   • Si cela fonctionne, le Credentials Proxy est accessible depuis l'extérieur du VPN.

   • Si ce n'est pas le cas, le client doit résoudre le problème de réseau interne ou de routage.

9. Testez la connexion depuis Orchestrator Cloud.Créez un nouveau Credentials Proxy lié à la même URL de proxy :

   • Si la création réussit, vous pouvez supprimer la connexion.

   • Si cela échoue, quelque chose bloque toujours la communication entre Orchestrator et Credentials Proxy.

     Remarque : À ce stade, Credentials Proxy doit être accessible publiquement sans restrictions de pare-feu ou liste blanche d'IP.
10. Récupérez la liste des adresses IP du locataire Orchestrator.

11. Ajoutez les IP à la liste d'autorisation pour l'accès à Credentials Proxy.

12. Depuis une machine en dehors du VPN, testez à nouveau le point de terminaison /api/v1/Health.Cela ne devrait pas fonctionner, car l'IP n'est pas ajoutée à la liste d'autorisation.
13. Dans Orchestrator Cloud, essayez de créer à nouveau un Credentials Proxy :
    • Si toutes les étapes ont été effectuées correctement, l'opération devrait désormais réussir.
    • Si elle échoue toujours, il peut y avoir un problème avec les règles de pare-feu ou de VPN empêchant la communication entre Orchestrator et Credentials Proxy.
14. Si le problème persiste, répétez attentivement les étapes ci-dessus et vérifiez chaque point de configuration.
15. Une fois le problème résolu, inversez le niveau de journal sur la machine Credentials Proxy à son paramètre d'origine.

Le proxy déconnecté ne démarre pas ou ne journalise pas

Le Credentials Proxy déconnecté effectue une étape de validation pendant le démarrage pour garantir qu'il peut répondre correctement aux demandes du client.Dans le cadre de ce processus, le proxy valide chaque configuration définie dans AppSettings:SecureStoreConfigurations.La logique de validation spécifique appliquée dépend du type de magasin d'informations d'identification configuré.

Dans certains cas, la cause première de l'échec du démarrage du proxy peut se produire si tôt dans le processus de démarrage que l'application n'atteint pas le point de générer ou d'écrire des événements dans le journal.

Causes possibles pour lesquelles l'application ne démarre pas

Plusieurs problèmes peuvent empêcher l'application Credentials Proxy de démarrer.Vous trouverez ci-dessous les causes courantes et comment les identifier.

• Pool d'applications IIS non démarré (Windows).Si le proxy est hébergé dans IIS, vérifiez que le pool d'applications qui lui est associé est en cours d'exécution. Vous pouvez vérifier cela dans le Gestionnaire IIS sous la section Pools d'applications.
• Configuration non valide dans appsettings.Production.json. Un fichier de configuration non valide ou incomplet peut provoquer l'échec du proxy pendant le démarrage. Vérifiez les exemples dans la section Exemples de configuration pour de plus amples détails.
• Configuration non valide dans AppSettings:SecureStoreConfigurations. La section définit la façon dont le proxy se connecte aux magasins d'informations d'identification et les valide.SecureStoreConfigurationsSi l'une de ces entrées est mal formée ou incomplète, l'application ne démarrera pas.
  • Paramètres non valides dans la configuration.Assurez-vous que tous les paramètres de configuration correspondent au type de magasin d'informations d'identification que vous utilisez.L'utilisation de paramètres ou de clés incorrects peut entraîner l'échec de la validation du démarrage.
  • Impossible d'accéder au coffre Si le magasin d'informations d'identification configuré s'appuie sur un coffre externe (par exemple, CyberArk, BeyondTrust ou autres), le démarrage peut échouer si le proxy ne peut pas l'atteindre ou s'authentifier avec.
• Autres problèmes liés à l'infrastructure.

Débogage

Lors du débogage de Credentials Proxy, l'objectif est d'éliminer le plus de variables possible avant de tester des configurations complexes.

• Commencez par utiliser une configuration minimale avec le type InMemorySecureStore. Cela vous permet de confirmer que le proxy peut démarrer avec succès avant d'introduire des dépendances externes.
  • Ajoutez le paramètre "UseInMemorySecureStore": "true",dans AppSettings.
  • Ajoutez ce qui suit dans AppSettings:SecureStoreConfigurations:

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

  • Le proxy ne doit plus présenter de problèmes liés à la configuration. S'il ne parvient toujours pas à démarrer, la cause est très probablement liée à l'infrastructure.
• Une fois que vous avez confirmé que le proxy démarre avec succès à l'aide de la configuration en mémoire, remplacez-le par votre configuration actuelle de magasin Credential (par exemple, CyberArk, BeyondTrust et autres).
  • Mettez à jour la SecureStoreConfigurations section en fonction de votre environnement et de votre type de magasin.

    Si l'application ne démarre pas correctement, vous devez trouver les journaux dans :

    • Le visualiseur d'événements Windows.

    • Le répertoire des journaux configuré du proxy.

  • Si l'application ne démarre pas et qu'aucun journal n'est généré, le problème est probablement lié à l'infrastructure ou aux autorisations dans votre environnement.

    Pour aider au débogage dans de tels cas, vous pouvez désactiver temporairement la validation du magasin sécurisé en ajoutant ce paramètre dans AppSettings:

    "SkipValidateSecureStoreConfigurations": true
    

    Remarque : Ce paramètre doit uniquement être utilisé à des fins de débogage.La validation du démarrage existe pour garantir que votre configuration de proxy est correcte et sécurisée.