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 le Credentials Proxy enregistre vraiment 200 requêtes, 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 maintenant être consignées.

Remarque : après chaque modification du fichier appsettings , vous devez redémarrer Credentials Proxy.

Si vous suivez ces étapes et qu'aucun journal supplémentaire n'est disponible en plus du démarrage et de l'arrêt, cela signifie qu'aucune requête n'atteigne l'Orchestrator Credentials Proxy. Cela est très probablement dû à un problème d'infrastructure ou de mise en réseau sur les machines Orchestrator Cloud Robot et Orchestrator Credentials Proxy.

Observateur d’événements

Tous les journaux doivent apparaître dans l’Observateur d’événements Windows pour les versions 2.0.0 et ultérieures de Orchestrator Credentials Proxy.

Modification de la destination du fichier journal

Pour modifier le chemin d'accès au fichier journal, ouvrez le fichier appsettings.production.json et utilisez le code suivant. Vous pouvez remplacer C:/dev/logs par 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. Lorsque vous le faites, annulez ces modifications, car cela produit un nombre excessif de journaux.

Les niveaux de journalisation par défaut ressemblent aux éléments suivants :

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

Si vous souhaitez obtenir plus de journaux, par exemple pour voir toutes les requêtes transmises au proxy, vous devez modifier le fichier appsettings.Production.json et ajouter les éléments suivants :

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

Si Information ne suffit pas et que vous voulez en savoir plus ou moins, vous pouvez utiliser les valeurs LogLevels de .Net. Pour plus d'informations, consultez la documentation Microsoft. Le fichier appsettings.json doit ressembler à ceci :

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

Redémarrez l’Orchestrator Credentials Proxy après avoir modifié le fichier appsettings .

Tester avec InMemoryStore

Si vous rencontrez des problèmes de débogage et que vous souhaitez effectuer une vérification auprès d'un type de magasin d'informations d'identification différent, vous pouvez utiliser le type InMemorySecureStore de Orchestrator Credentials Proxy.

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

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

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

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

Impossible de se connecter au proxy connecté

Lorsque vous configurez une connexion Orchestrator Credentials Proxy et que vous tentez de la lier à Orchestrator, vous pouvez rencontrer le message d'erreur suivant :

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

Pendant le processus de connexion, Orchestrator exécute une simple requête GET vers le point de terminaison du proxy /api/v1/Health .

Le but de cette requête est de vérifier que le proxy est accessible depuis l'environnement cloud Orchestrator. Si cette requête échoue, cela indique qu’Orchestrator ne peut pas accéder au proxy et que la vérification de la connexion ne sera pas transmise.

Problèmes couramment rencontrés

• L’Orchestrator Credentials Proxy n’est pas démarré :

  • Accédez au serveur où le 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 du proxy d'informations d'identification 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 l'Orchestrator Credentials Proxy, confirmez qu'il utilise également une connexion HTTPS sécurisée.

• Le 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 la configuration de votre réseau.
  • Assurez-vous que les adresses IP sortantes d’Orchestrator sont correctement mises sur liste blanche. Consultez la page Adresses IP sortantes d'Orchestrator pour plus d'informations.
    Remarque : si votre organisation a plusieurs locataires, ils peuvent être hébergés dans différentes régions et utiliser différentes adresses IP. Vérifiez chaque locataire.
• Problème de point de terminaison non authentifié en raison d’une heure de 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 à enquêter

1. Vérifiez dans IIS que le Orchestrator Credentials Proxy est en cours d'exécution.
2. Vérifiez dans le navigateur que l'URL du proxy d'informations d'identification est accessible et se charge correctement.
3. Vérifiez dans le navigateur que l'URL du proxy d'informations d'identification est sécurisée.
4. Sur la machine Credentials Proxy, passez le niveau de journalisation sur Information pour le dépannage. de annuler cette modification une fois l'enquête terminée.
5. Testez le point de terminaison de santé localement. Sur la machine Credentials Proxy, ouvrez Swagger ou utilisez un outil tel que Postman pour faire une demande :

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

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

6. Accès de test dans le VPN. À partir d’une autre machine appartenant au même VPN, vérifiez que l’URL du proxy d’informations d’identification est accessible. Envoyez une requête au même point de terminaison /api/v1/Health :

   • Si cela fonctionne, le Credentials Proxy est accessible depuis le 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 point de terminaison /api/v1/Health :

   • 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 à partir du Cloud Orchestrator. Créez un nouveau Credentials Proxy lié à la même URL de proxy :

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

   • En cas d'échec, quelque chose bloque toujours la communication entre Orchestrator et le proxy d'informations d'identification.

     Remarque : à ce stade, le Credentials Proxy doit être accessible au public, sans restrictions de pare-feu ni mise sur liste blanche d'IP.
10. Récupérez la liste des adresses IP des locataires Orchestrator.

11. Ajoutez les adresses IP à la liste d’autorisation pour accéder au Credentials Proxy.

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

Le proxy déconnecté ne démarrera pas et ne se consignera pas

Le Credentials Proxy en mode déconnecté effectue une étape de validation au démarrage pour s'assurer qu'il peut répondre correctement aux requêtes des clients. 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 profonde 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 de journal.

Causes possibles que l'application ne démarre pas

Plusieurs problèmes peuvent empêcher le démarrage de l'application Credentials Proxy . Voici 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 le vérifier 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 entraîner l’échec du proxy lors du démarrage. Consultez les exemples dans la section Exemples de configuration pour plus de détails.
• Configuration non valide dans AppSettings:SecureStoreConfigurations. La section SecureStoreConfigurations définit comment le proxy se connecte aux magasins d’informations d’identification et valide ceux-ci. Si l’une de ces entrées est incorrecte 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é repose 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 celui-ci.
• Autres problèmes liés à l’infrastructure.

Débogage

Lors du débogage du 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 les éléments suivants dans AppSettings:SecureStoreConfigurations:

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

  • Le proxy ne devrait plus rencontrer de problèmes liés à la configuration. Si le système ne démarre toujours pas, la cause est très probablement liée à l'infrastructure.
• Une fois que vous avez confirmé que le proxy commence à utiliser avec succès la configuration en mémoire, remplacez-le par votre configuration réelle de magasin d'informations d'identification (par exemple, CyberArk, BeyondTrust et d'autres).
  • Mettez à jour la section SecureStoreConfigurations en fonction de votre environnement et du type de magasin.

    Si l'application ne démarre pas, vous devriez trouver des journaux dans :

    • L' Observateur d'événements dans 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 de votre environnement.

    Pour faciliter le 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 de démarrage existe pour s’assurer que votre configuration de proxy est correcte et sécurisée.