- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Verwalten großer Bereitstellungen
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Schreibgeschütztes Orchestrator-Replikat
- Exportieren von Rastern im Hintergrund
- Mandant
- Über den Kontext „Mandant“
- Suche nach Ressourcen in einem Mandanten
- Verwaltung von Robotern
- Verbindung von Robotern mit Orchestrator
- Speicherung von Roboterzugangsdaten in CyberArk
- Speichern der Kennwörter von Unattended-Robotern im Azure Key Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im HashiCorp Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im AWS Secrets Manager (schreibgeschützt)
- Löschen von getrennten und nicht reagierenden Unattended-Sitzungen
- Roboter-Authentifizierung
- Roboter-Authentifizierung mit Client-Anmeldeinformationen
- SmartCard-Authentifizierung
- Konfigurieren von Automatisierungsfunktionen
- Audit
- Einstellungen – Mandantenebene
- Ressourcenkatalogdienst
- Ordnerkontext
- Automatisierungen
- Prozesse
- Jobs
- Auslöser
- Protokolle
- Überwachung
- Warteschlangen
- Assets
- Speicher-Buckets
- Testverfahren in Orchestrator
- Sonstige Konfigurationen
- Integrationen
- Hostverwaltung
- Über die Hostebene
- Verwalten von Systemadministratoren
- Verwalten von Mandanten
- Konfigurieren von System-E-Mail-Benachrichtigungen
- Prüfungsprotokolle für das Hostportal
- Wartungsmodus
- Organisationsadministration
- Fehlersuche und ‑behebung

Orchestrator-Anleitung
Über den Identity Server
UiPath® Identity Server ist der Authentifizierungsdienst des eigenständigen Orchestrators.Es bietet eine sichere Authentifizierung und Tokenausgabe für Orchestrator und seine Verwaltungsportale.Identity Server implementiert die Standards OAuth 2.0 und OpenID Connect und lässt sich in Enterprise-Identitätssysteme wie Active Directory integrieren.Im folgenden Diagramm finden Sie Informationen zur Funktionsweise von Identity Server im eigenständigen Orchestrator.
Abbildung 1. Identity Server-Diagramm

Rolle innerhalb von Orchestrator
Identity Server ist verantwortlich für:
- Authentifizieren von Benutzern und Anwendungen, die auf Orchestrator zugreifen
- Zugriffs- und Identitätstoken ausstellen
- Unterstützung von OAuth-2.0- und OpenID-Connect-Flows
- Integration mit externen Identitätsanbietern (z. B. Active Directory, SAML-Anbieter)
- Single Sign-On (SSO) aktivieren
- Sichern der Kommunikation zwischen Orchestrator und dem Identity Management Portal
Orchestrator und seine Verwaltungsportale sind zur Authentifizierung auf Identity Server angewiesen.
Authentifizierungsflow in Orchestrator
- Benutzerauthentifizierung
Wenn Sie auf den Orchestrator oder das Identitätsverwaltungsportal zugreifen:
- Die Anforderung wird an Identity Server umgeleitet.
- Identity Server validiert den Benutzer anhand von:
- Lokale Konten, oder
- Externe Identitätsanbieter (z. B. Active Directory, SAML).
- Bei erfolgreicher Authentifizierung stellt Identity Server ein Sicherheitstoken aus.
- Tokenbasierter Zugriff
Nach der Authentifizierung:
- Ein OAuth-Zugriffstoken wird ausgestellt.
- Das Token begleitet nachfolgende Anfragen an Orchestrator.
- Orchestrator validiert das Token.
- Rollen und Berechtigungen bestimmen die Autorisierung.Identity Server übernimmt die Authentifizierung.Orchestrator erzwingt die Autorisierung.
Integration von Active Directory und Kerberos
In domänenverbundenen Umgebungen unterstützt der eigenständige Orchestrator die Kerberos-basierte Authentifizierung:
- Der Client löst den Orchestrator-Hostnamen mithilfe von DNS auf.
- Der Client erhält ein Kerberos Ticket Granting Ticket (TGT) von Active Directory.
- Der Client fordert ein Dienstticket für den konfigurierten Dienstprinzipalnamen (SPN) an.
- Der IIS-Webserver validiert das Kerberos-Ticket.
- Identity Server verarbeitet die authentifizierte Identität und stellt ein Plattformtoken aus.
Dies ermöglicht ein nahtloses Single Sign-On in Enterprise-Windows-Umgebungen.
Überlegungen zur hohen Verfügbarkeit
In Bereitstellungen mit mehreren Knoten:
- Identity Server läuft auf mehreren Knoten hinter einem Load Balancer.
- Clients greifen über einen gemeinsam genutzten Load-Balancer-Hostnamen auf Orchestrator und Identity Server zu.
- Redis speichert OAuth-Clientdaten und den Sitzungsstatus über Knoten hinweg zwischen und gewährleistet so eine konsistente Authentifizierung im gesamten Cluster.
- Der Service Principal Name (SPN) muss mit dem Hostnamen des Load Balancers übereinstimmen, wenn Kerberos verwendet wird.
- Wenn Sie von einem Setup mit einem einzelnen Knoten zu einem Setup mit mehreren Knoten wechseln, müssen Sie die öffentliche URL des Identity Server in der Datenbank und in der Datei UiPath.Orchestrator.dll.config aktualisieren.
Authentifizierung der externen Anwendung
Orchestrator unterstützt sicheren Zugriff für
- Externe Anwendungen
- API-Integrationen
- Kommunikation zwischen Roboter und Orchestrator
Anwendungen authentifizieren sich mit unterstützten OAuth-Flows (z. B. ROPC) und erhalten Token von Identity Server.
Sicherheitsmodell
Der eigenständige Orchestrator verwendet ein zentrales Authentifizierungsmodell:
- Identity Server führt die Authentifizierung durch.
- Orchestrator erzwingt die Autorisierung.
- Der tokenbasierte Zugriff sichert APIs und die Orchestrator-UI.
- Die Integration mit externen Identitätsanbietern (Active Directory, SAML) unterstützt Enterprise-Sicherheitsanforderungen.