Debugging mit dem Orchestrator Credentials Proxy

Protokolle

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

Um zu aktivieren, ob der Credentials Proxy wirklich 200 Anforderungen protokolliert, starten Sie den Orchestrator Credentials Proxy auf dem lokalen Server, gehen Sie zu Swagger und führen Sie den Endpunkt Zustand (nicht authentifiziert) aus: api/v1/Health.Die Anforderungen sollten jetzt 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 außer dem Starten und Herunterfahren keine zusätzlichen Protokolle verfügbar sind, bedeutet dies, dass keine Anforderungen den Orchestrator Credentials Proxy erreichen. Dies wird höchstwahrscheinlich durch ein Infrastruktur- oder Netzwerkproblem der Orchestrator Cloud Robot und der 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 Protokolldatei-Ziels

Um den Pfad der Protokolldatei 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 Debugging verwendet werden. Wenn Sie fertig sind, setzen Sie diese Änderungen zurück, da dies zu viele Protokolle erzeugt.

Die Standardprotokollierungsebenen sehen wie folgt aus:

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

Wenn Sie mehr Protokolle erhalten möchten, um beispielsweise alle Anforderungen an den Proxy zu sehen, müssen Sie die appsettings.Production.json Datei bearbeiten und Folgendes hinzufügen:

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

Wenn die Werte Informationnicht ausreichen und Sie mehr oder weniger möchten, können Sie die LogLevelsWerte aus .Net verwenden. Aktivieren Sie für weitere Informationen die Microsoft-Dokumentation.Die appsettings.json Datei 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 nach dem Ändern der Datei appsettingsneu.

Testen mit InMemoryStore

Wenn Sie Probleme beim Debuggen haben und mit einem anderen credential store Typ überprüfen möchten, können Sie den Orchestrator Credentials Proxy InMemorySecureStoreTyp verwenden.

Hinweis: Verwenden Sie dieses Verfahren nur für Testzwecke.

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

Um sie für getrennte Proxys zu aktivieren, nehmen Sie auch Folgendes in den SecureStoreConfigurationsAbschnitt auf:

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

Verbundener Proxy konnte keine Verbindung herstellen

Beim Einrichten einer Orchestrator Credentials Proxy-Verbindung und beim Versuch, sie mit Orchestrator zu verknüpfen, wird möglicherweise folgende Fehlermeldung angezeigt:

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

Während des Verbindungsprozesses führt Orchestrator eine einfache GET-Anforderung an den /api/v1/Health Proxy-Endpunkt durch.

Der Zweck dieser Anforderung besteht darin, zu überprüfen, ob der Proxy über die Orchestrator-Cloud-Umgebung erreichbar ist. Wenn diese Anforderung fehlschlägt, zeigt dies an, dass Orchestrator nicht auf den Proxy zugreifen kann und die Verbindungsprüfung nicht besteht.

Häufige Probleme

• Der Orchestrator Credentials Proxy wird nicht gestartet:

  • Gehen Sie zu dem Server, auf dem der Orchestrator Credentials Proxy installiert ist.

  • Stellen Sie in IIS sicher, dass die Credentials Proxy-Anwendung ausgeführt wird.

  • Öffnen Sie auf demselben Server einen Browser und aktivieren Sie die Credentials Proxy-URL, um sicherzustellen, dass sie lokal zugänglich ist.

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

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

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

• Der Orchestrator Credentials Proxy wird hinter einer Firewall, einem VPN oder einer ähnlichen Netzwerkeinschränkung blockiert. Wenn der Credentials Proxy von Orchestrator aus nicht erreichbar ist, überprüfen Sie Ihre Netzwerkkonfiguration.
  • Stellen Sie sicher, dass die ausgehenden Orchestrator-IPs ordnungsgemäß freigegeben sind.Aktivieren Sie die Seite Orchestrator-Ausgehende IP-Adressen für weitere Informationen.
    Hinweis: Wenn Ihre Organisation mehrere Mandanten hat, können diese in verschiedenen Regionen gehostet werden und unterschiedliche IP-Adressen verwenden.Für jeden Mandanten überprüfen.
• Problem mit dem nicht authentifizierten Endpunkt aufgrund einer falschen Serverzeit.
  • Wenn der nicht authentifizierte Endpunkt fehlschlägt, ist es möglich, dass die Serverzeit nicht korrekt eingestellt ist. Wenn die Systemuhr ungenau ist, interpretiert der Server JWT Token möglicherweise als ungültig.

Schritte zur Untersuchung

1. Überprüfen Sie im IIS, ob der Orchestrator Credentials Proxy ausgeführt wird.
2. Aktivieren Sie im Browser, ob die Credentials Proxy-URL zugänglich ist und korrekt geladen wird.
3. Aktivieren Sie im Browser, ob die Credentials Proxy-URL sicher ist.
4. Erhöhen Sie auf der Credentials Proxy Maschine die Protokollierungsstufe auf Informationen für die Fehlerbehebung. 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. Zugriff innerhalb des VPN testen. Aktivieren Sie von einer anderen Maschine innerhalb desselben VPN (z. B. dem Laptop eines Kunden oder der Robotermaschine eines Kunden), ob die Credentials Proxy-URL zugänglich ist.Anfordern Sie denselben /api/v1/HealthEndpunkt:

   • Wenn es funktioniert, ist der Credentials Proxy aus dem VPN erreichbar.

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

7. Öffentliche Zugänglichkeit testen.
8. Aktivieren Sie auf einer Maschine, die sich nicht im VPN befindet, den /api/v1/HealthEndpunkt:

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

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

9. Testen Sie die Verbindung aus der 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 es fehlschlägt, blockiert immer noch etwas die Kommunikation zwischen Orchestrator und dem Credentials Proxy.

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

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

12. Testen Sie den Endpunkt erneut von einer Maschine außerhalb des VPN/api/v1/Health.Es sollte nicht funktionieren, da die IP nicht zur Allowlist hinzugefügt wurde.
13. Versuchen Sie in der Orchestrator Cloud erneut, einen Credentials Proxy zu erstellen:
    • Wenn alle Schritte korrekt abgeschlossen wurden, sollte es jetzt erfolgreich sein.
    • Wenn es weiterhin fehlschlägt, kann ein Problem mit Firewall- oder VPN-Regeln vorliegen, die die Kommunikation zwischen 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 Credentials Proxy-Maschine auf die ursprüngliche Einstellung zurück.

Der getrennte 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 bearbeiten kann. Als Teil dieses Prozesses validiert der Proxy jede Konfiguration, die in AppSettings:SecureStoreConfigurations. definiert ist. Die spezifische angewendete Validierungslogik hängt vom Typ des konfigurierten Credential-Speichers ab.

In bestimmten Fällen kann die Ursache für das fehlgeschlagene Starten des Proxys so früh im Startprozess auftreten, dass die Anwendung nicht den Punkt erreicht, an dem Protokollereignisse generiert oder geschrieben werden.

Mögliche Ursachen dafür, dass die App nicht gestartet wird

Mehrere Probleme können das Starten der Credentials Proxy-Anwendung verhindern. Nachfolgend finden Sie häufige Ursachen und wie Sie sie identifizieren.

• IIS-Anwendungspool wurde nicht gestartet (Windows). Wenn der Proxy in IIS gehostet wird, stellen Sie sicher, dass der damit verknüpfte Anwendungspool ausgeführt wird. Sie können dies im IIS-Manager im Abschnitt Anwendungspools aktivieren.
• Ungültige Konfiguration in appsettings.Production.json. Eine ungültige oder unvollständige Konfigurationsdatei kann dazu führen, dass der Proxy während des Starts fehlschlägt. Aktivieren Sie die Beispiele im Abschnitt Konfigurationsbeispiele für weitere Details.
• Ungültige Konfiguration in AppSettings:SecureStoreConfigurations. Der Abschnitt definiert, wie der Proxy eine Verbindung mit Credential-Speichern herstellt und diese validiert.SecureStoreConfigurationsWenn einer dieser Einträge fehlerhaft formiert 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 Credential-Typ übereinstimmen.Die Verwendung falscher Parameter oder Schlüssel kann dazu führen, dass die Startvalidierung fehlschlägt.
  • Zugriff auf den Tresor nicht möglich. Wenn der konfigurierte Credential-Speicher auf einem externen Tresor (z. B. CyberArk, BeyondTrust oder andere) basiert, kann der Start fehlschlagen, wenn der Proxy ihn nicht erreichen oder sich damit authentifizieren kann.
• Andere infrastrukturbezogene Probleme.

Debugging

Beim Debuggen des Credentials-Proxy besteht das Ziel darin, so viele Variablen wie möglich zu eliminieren, bevor komplexe Konfigurationen getestet werden.

• Beginnen Sie mit einer minimalen Konfiguration mit dem Typ InMemorySecureStore. Dadurch können Sie vor der Einführung externer Abhängigkeiten bestätigen, dass der Proxy erfolgreich gestartet werden kann.
  • Fügen Sie den "UseInMemorySecureStore": "true", Parameter in hinzuAppSettings.
  • Fügen Sie Folgendes in hinzuAppSettings:SecureStoreConfigurations:

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

  • Der Proxy sollte keine konfigurationsbezogenen Probleme mehr haben. Wenn es immer noch nicht startet, ist die Ursache höchstwahrscheinlich infrastrukturbedingt.
• Sobald Sie bestätigt haben, dass der Proxy erfolgreich die In-Memory-Konfiguration verwendet, ersetzen Sie sie durch Ihre tatsächliche Einrichtung für den Credential-Speicher (z. B. CyberArk, BeyondTrust und andere).
  • Aktualisieren Sie den SecureStoreConfigurations Abschnitt basierend auf Ihrer Umgebung und Ihrem Speichertyp.

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

    • Die Windows-Ereignisanzeige.

    • Das konfigurierte Protokollverzeichnis des Proxy.

  • 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 das Debugging in solchen Fällen zu erleichtern, können Sie die Validierung des sicheren Speichers vorübergehend deaktivieren, indem Sie diesen Parameter in AppSettingshinzufügen:

    "SkipValidateSecureStoreConfigurations": true
    

    Hinweis: Dieser Parameter sollte nur für Debugging-Zwecke verwendet werden. Die Startvalidierung dient dazu, sicherzustellen, dass Ihre Proxykonfiguration korrekt und sicher ist.