Debugging mit dem Orchestrator Credentials Proxy

Protokolle

Standardmäßig protokolliert der Orchestrator Credentials Proxy alle Ausnahmen und die Informationen zum ersten Starten und Herunterfahren.

Um zu überprüfen, ob der Credentials Proxy wirklich 200 Anforderungen protokolliert, starten Sie den Orchestrator Credentials Proxy auf dem lokalen Server, wechseln Sie zu Swagger und führen Sie den Health (nicht authentifizierten) Endpunkt aus: api/v1/Health. Die Anforderungen sollten nun protokolliert werden.

Hinweis: Nach jeder Änderung an der appsettings -Datei müssen Sie den Credentials Proxy neu starten.

Wenn Sie diese Schritte ausführen und neben dem Starten und Herunterfahren keine weiteren Protokolle verfügbar sind, bedeutet das, dass keine Anforderungen den Orchestrator Credentials Proxy erreichen. Dies wird wahrscheinlich durch ein Infrastruktur- oder Netzwerkproblem auf den Maschinen Orchestrator Cloud Robot und Orchestrator Credentials Proxy verursacht.

Ereignisanzeige

Alle Protokolle sollten in der Windows-Ereignisanzeige für Orchestrator Credentials Proxy-Versionen 2.0.0 und höher angezeigt werden.

Ändern des Ziels der Protokolldatei

Um den Protokolldateipfad zu ändern, öffnen Sie die appsettings.production.json -Datei und verwenden Sie den folgenden Code. Sie können C:/dev/logs durch den gewünschten Pfad ersetzen:

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

Zusätzliche Protokolle

Hinweis: Dieses Verfahren sollte nur für das Debuggen verwendet werden. Wenn Sie fertig sind, machen Sie diese Änderungen rückgängig, da dadurch zu viele Protokolle erzeugt werden.

Die standardmäßigen Protokollierungsstufen sehen wie folgt aus:

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

Wenn Sie weitere Protokolle erhalten möchten, z. B. um alle Anforderungen anzuzeigen, die zum Proxy kommen, müssen Sie die Datei appsettings.Production.json bearbeiten und Folgendes hinzufügen:

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

Wenn Information nicht ausreicht und Sie mehr oder weniger möchten, können Sie die LogLevels -Werte von .Net verwenden. Weitere Informationen finden Sie in der Microsoft-Dokumentation. Die Datei appsettings.json sollte wie folgt aussehen:

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

Starten Sie den Orchestrator Credentials Proxy neu, nachdem Sie die appsettings -Datei geändert haben.

Testen Sie mit InMemoryStore

Wenn beim Debuggen Probleme auftreten und Sie dies mit einem anderen Anmeldeinformationsspeichertyp überprüfen möchten, können Sie den Orchestrator Credentials Proxy-Typ InMemorySecureStore verwenden.

Hinweis: Verwenden Sie dieses Verfahren nur zu Testzwecken.

Um den Typ InMemorySecureStore zu aktivieren, öffnen Sie die Datei appsettings.production.json , wechseln Sie zum Abschnitt AppSettings und fügen Sie den Parameter "UseInMemorySecureStore": "true" hinzu.

Um sie für getrennte Proxys zu aktivieren, fügen Sie auch Folgendes in den Abschnitt SecureStoreConfigurations ein:

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

Verbundener Proxy konnte keine Verbindung herstellen

Wenn Sie eine Orchestrator Credentials Proxy-Verbindung einrichten und versuchen, sie mit dem Orchestrator zu verknüpfen, wird möglicherweise die folgende Fehlermeldung angezeigt:

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

Während des Verbindungsvorgangs führt der Orchestrator eine einfache GET- Anforderung an den /api/v1/Health -Proxyendpunkt aus.

Der Zweck dieser Anforderung ist es, zu überprüfen, ob der Proxy von der Orchestrator-Cloudumgebung aus erreichbar ist. Wenn diese Anforderung fehlschlägt, zeigt sie an, dass der Orchestrator nicht auf den Proxy zugreifen kann und die Verbindungsprüfung nicht bestanden wird.

Häufige Probleme

• Der Orchestrator Credentials Proxy wurde nicht gestartet:

  • Wechseln Sie zum Server, auf dem der Orchestrator Credentials Proxy installiert ist.

  • Stellen Sie in IIS sicher, dass die Proxyanwendung für Anmeldeinformationen ausgeführt wird.

  • Öffnen Sie auf demselben Server einen Browser und überprüfen Sie, ob die URL des Proxys für Anmeldeinformationen lokal zugänglich ist.

• Die Verbindung verfügt nicht über ein gültiges HTTPS/SSL-Zertifikat. Die gesamte Kommunikation zwischen dem Orchestrator und OCP muss sicher sein.

  • Stellen Sie sicher, dass Ihr Credentials Proxy ein gültiges HTTPS/SSL-Zertifikat verwendet.

  • (Optional) Wenn ein Lastausgleich vor dem Orchestrator Credentials Proxy konfiguriert wird, bestätigen Sie, dass er auch eine sichere HTTPS-Verbindung verwendet.

• Der Orchestrator Credentials Proxy wird hinter einer Firewall, einem VPN oder einer ähnlichen Netzwerkbeschränkung blockiert. Wenn der Anmeldeinformationsproxy von Orchestrator aus nicht erreichbar ist, überprüfen Sie Ihre Netzwerkkonfiguration.
  • Stellen Sie sicher, dass die ausgehenden Orchestrator-IPs ordnungsgemäß auf die weiße Liste gesetzt werden. Weitere Informationen finden Sie auf der Seite Orchestrator-IP-Adressen für ausgehende Verbindungen.
    Hinweis: Wenn Ihre Organisation über mehrere Mandanten verfügt, werden diese möglicherweise in verschiedenen Regionen gehostet und verwenden unterschiedliche IP-Adressen. Überprüfen Sie dies für jeden Mandanten.
• Problem mit nicht authentifizierten Endpunkten aufgrund einer falschen Serverzeit.
  • Wenn der nicht authentifizierte Endpunkt fehlschlägt, ist die Serverzeit möglicherweise nicht korrekt festgelegt. Wenn die Systemuhr ungenau ist, interpretiert der Server JWT-Token möglicherweise als ungültig.

Zu untersuchende Schritte

1. Stellen Sie in IIS sicher, dass der Orchestrator Credentials Proxy ausgeführt wird.
2. Überprüfen Sie im Browser, ob die URL des Proxys für Anmeldeinformationen zugänglich ist und korrekt geladen wird.
3. Überprüfen Sie im Browser, ob die URL des Proxys für Anmeldeinformationen sicher ist.
4. Erhöhen Sie auf der Proxymaschine für Anmeldeinformationen die Protokollierungsstufe zur Fehlerbehebung auf Information . Denken Sie daran, diese Änderung nach Abschluss der Untersuchung rückgängig zu machen.
5. Testen Sie den Integritätsendpunkt lokal. Öffnen Sie auf der Credentials Proxy-Maschine Swagger oder verwenden Sie ein Tool wie Postman , um eine Anforderung zu stellen an:

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

   Eine erfolgreiche Antwort zeigt an, dass der Proxy lokal erreichbar und betriebsbereit ist.

6. Testzugriff innerhalb des VPN. Überprüfen Sie von einer anderen Maschine innerhalb desselben VPN (z. B. einem Laptop oder einer Robotermaschine eines Kunden), ob die URL des Proxys für Anmeldeinformationen zugänglich ist. Stellen Sie eine Anforderung an denselben /api/v1/Health -Endpunkt:

   • Wenn es funktioniert, ist der Credentials Proxy innerhalb des VPN erreichbar.

   • Ist dies nicht der Fall, muss der Client das interne Netzwerk- oder Routing-Problem beheben.

7. Testen Sie die öffentliche Zugänglichkeit.
8. Überprüfen Sie auf einer Maschine, die sich nicht innerhalb des VPN befindet, den /api/v1/Health -Endpunkt:

   • Wenn es funktioniert, ist der Credentials Proxy von außerhalb des VPN erreichbar.

   • Ist dies nicht der Fall, muss der Client das interne Netzwerk- oder Routing-Problem beheben.

9. Testen Sie die Verbindung über die Orchestrator-Cloud. Erstellen Sie einen neuen Credentials Proxy, der mit derselben Proxy-URL verknüpft ist:

   • Wenn die Erstellung erfolgreich ist, können Sie die Verbindung löschen.

   • Wenn sie fehlschlägt, blockiert etwas immer noch die Kommunikation zwischen dem Orchestrator und dem Credentials Proxy.

     Hinweis: Zu diesem Zeitpunkt sollte der Credentials Proxy öffentlich zugänglich sein, ohne Firewall-Einschränkungen oder IP-Whitelisting.
10. Rufen Sie die Liste der IP-Adressen der Orchestrator-Mandanten ab.

11. Fügen Sie die IPs zur Zulassungsliste für den Zugriff auf den Credentials Proxy hinzu.

12. Testen Sie den /api/v1/Health -Endpunkt erneut von einer Maschine außerhalb des VPN. Dies sollte nicht funktionieren, da die IP nicht zur Zulassungsliste hinzugefügt wird.
13. Versuchen Sie in der Orchestrator Cloud erneut, einen Credentials Proxy zu erstellen:
    • Wenn alle Schritte korrekt abgeschlossen wurden, sollte der Vorgang nun erfolgreich sein.
    • Wenn sie immer noch fehlschlägt, liegt möglicherweise ein Problem mit Firewall- oder VPN-Regeln vor, die die Kommunikation zwischen dem Orchestrator und dem Credentials Proxy verhindern.
14. Wenn das Problem weiterhin besteht, wiederholen Sie die obigen Schritte sorgfältig und überprüfen Sie jeden Konfigurationspunkt.
15. Sobald das Problem behoben ist, setzen Sie die Protokollebene auf der Proxymaschine für Anmeldeinformationen auf die ursprüngliche Einstellung zurück.

Getrennter Proxy wird nicht gestartet oder protokolliert

Der getrennte Credentials Proxy führt während des Starts einen Validierungsschritt durch, um sicherzustellen, dass er Clientanforderungen korrekt verarbeiten kann. Als Teil dieses Prozesses überprüft der Proxy jede in AppSettings:SecureStoreConfigurations definierte Konfiguration. Die spezifische Validierungslogik hängt vom Typ des konfigurierten Anmeldeinformationsspeichers ab.

In bestimmten Fällen kann die Ursache dafür, dass der Proxy nicht gestartet werden kann, so früh im Startprozess auftreten, dass die Anwendung noch nicht den Punkt erreicht, an dem Protokollereignisse generiert oder geschrieben werden.

Mögliche Ursachen, dass die App nicht gestartet wird

Mehrere Probleme können den Start der Credentials Proxy- Anwendung verhindern. Im Folgenden finden Sie häufige Ursachen und wie Sie sie identifizieren können.

• IIS-Anwendungspool nicht gestartet (Windows). Wenn der Proxy in IIS gehostet wird, stellen Sie sicher, dass der zugehörige Anwendungspool ausgeführt wird. Sie können dies im IIS-Manager im Abschnitt Anwendungspools überprüfen.
• Ungültige Konfiguration in appsettings.Production.json. Eine ungültige oder unvollständige Konfigurationsdatei kann dazu führen, dass der Proxy beim Start fehlschlägt. Weitere Informationen finden Sie in den Beispielen im Abschnitt Konfigurationsbeispiele .
• Ungültige Konfiguration in AppSettings:SecureStoreConfigurations. Im Abschnitt SecureStoreConfigurations wird definiert, wie der Proxy eine Verbindung mit Anmeldeinformationsspeichern herstellt und diese validiert. Wenn einer dieser Einträge falsch formatiert oder unvollständig ist, wird die Anwendung nicht gestartet.
  • Ungültige Parameter in der Konfiguration. Stellen Sie sicher, dass alle Konfigurationsparameter mit dem von Ihnen verwendeten Anmeldeinformationsspeichertyp übereinstimmen. Die Verwendung falscher Parameter oder Schlüssel kann dazu führen, dass die Startvalidierung fehlschlägt.
  • Der Zugriff auf den Tresor ist nicht möglich. Wenn der konfigurierte Anmeldeinformationsspeicher von einem externen Vault abhängt (z. B. CyberArk, BeyondTrust oder andere), kann der Start fehlschlagen, wenn der Proxy ihn nicht erreichen oder sich bei ihm authentifizieren kann.
• Andere Probleme im Zusammenhang mit der Infrastruktur.

Debugging

Beim Debuggen des Credentials Proxys müssen so viele Variablen wie möglich eliminiert werden, bevor komplexe Konfigurationen getestet werden.

• Beginnen Sie mit einer Minimalkonfiguration mit dem Typ InMemorySecureStore . Dadurch können Sie bestätigen, dass der Proxy erfolgreich gestartet werden kann, bevor externe Abhängigkeiten eingeführt werden.
  • Fügen Sie den Parameter "UseInMemorySecureStore": "true", in AppSettings hinzu.
  • Fügen Sie Folgendes in AppSettings:SecureStoreConfigurations hinzu:

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

  • Der Proxy sollte keine konfigurationsbezogenen Probleme mehr haben. Wenn er immer noch nicht gestartet werden kann, liegt die Ursache wahrscheinlich in der Infrastruktur.
• Wenn Sie bestätigt haben, dass der Proxy erfolgreich mit der Verwendung der In-Memory-Konfiguration beginnt, ersetzen Sie sie durch Ihre tatsächliche Anmeldeinformationsspeichereinrichtung (z. B. CyberArk, BeyondTrust und andere).
  • Aktualisieren Sie den Abschnitt SecureStoreConfigurations basierend auf Ihrer Umgebung und dem Speichertyp.

    Wenn die Anwendung nicht gestartet werden kann, finden Sie Protokolle entweder in:

    • Die Windows-Ereignisanzeige.

    • Das konfigurierte Protokollverzeichnis des Proxys.

  • Wenn die Anwendung nicht gestartet wird und keine Protokolle generiert werden, hängt das Problem wahrscheinlich mit der Infrastruktur oder Berechtigungen in Ihrer Umgebung zusammen.

    Um in solchen Fällen das Debuggen zu unterstützen, können Sie die Validierung sicherer Speicher vorübergehend deaktivieren, indem Sie diesen Parameter in AppSettings hinzufügen:

    "SkipValidateSecureStoreConfigurations": true

    Hinweis: Dieser Parameter darf nur zu Debugzwecken verwendet werden. Die Startvalidierung dient dazu, sicherzustellen, dass Ihre Proxykonfiguration korrekt und sicher ist.