- 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 von Unattended-Roboterkennwörtern in 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
- Audit
- Ressourcenkatalogdienst
- Ordnerkontext
- Automatisierungen
- Prozesse
- Jobs
- Auslöser
- Protokolle
- Überwachung
- Warteschlangen
- Assets
- Speicher-Buckets
- Test Suite - Orchestrator
- Hostverwaltung
- Identity Server
- Authentication
- Organisationsadministration
- Sonstige Konfigurationen
- Integrationen
- Klassische Roboter
- Fehlersuche und ‑behebung
Kontotypen
Here's an overview of the different account types available in the UiPath platform, helping you understand and manage identities within the platform. Identities can come in the form of user accounts, robot accounts, external applications, and groups.
All objects or individual ones can be viewed and managed from their dedicated tabs.
Ein Konto, das vom Orchestrator über das Verwaltungsportal erstellt und verwaltet werden kann, gilt im Ökosystem von UiPath als lokal.
Für lokale Konten werden alle Kontoattribute wie Name und E-Mail-Adresse im Identity Server gespeichert.
Benutzerkonten, die aus einem Verzeichnis außerhalb des UiPath-Ökosystems stammen (z. B. aus Azure Active Directory), sind Verzeichnisbenutzer. Diese Konten können auf den Orchestrator zugreifen und Rollen erhalten, wenn Sie in das Verzeichnis integrieren.
Für Verzeichnisbenutzer werden nur Rollenzuweisungen und Orchestrator-spezifische Einstellungen innerhalb des UiPath-Ökosystems, im Identity Server und im Orchestrator, verwaltet. Der externe Verzeichnisadministrator verwaltet kontospezifische Attribute (Name, E-Mail, Verzeichnisgruppenmitgliedschaft).
Es gibt zwei Möglichkeiten, wie ein Verzeichnisbenutzer Zugriff auf den Orchestrator erhalten kann:
- Ein Administrator weist dem Verzeichniskonto im Orchestrator Rollen zu – wir bezeichnen dies als individuell hinzugefügtes Konto.
- Ein Administrator fügt das Verzeichniskonto zu einer Gruppe hinzu und der Benutzer meldet sich mit dem Verzeichniskonto an.
- Ein Orchestrator-Administrator fügt eine Verzeichnisgruppe zu einer lokalen Gruppe hinzu, dann fügt ein Verzeichnisadministrator das Benutzerkonto zu der Verzeichnisgruppe hinzu – wir bezeichnen dies als automatisch bereitgestelltes Konto.
Unabhängig von ihrem Typ erben Verzeichniskonten immer die Rollen der Gruppen, zu denen sie gehören, sofern diese im Orchestrator vorhanden sind.
Lokale Gruppen sind Entitäten, die aus dem Identity Server stammen und eine Sammlung von Benutzer- und Roboterkonten darstellen. Sie können Rollen und Lizenzen zu Gruppen zuweisen, anstatt sie einzelnen Benutzern zuzuweisen. Alles, was der Gruppe zugewiesen ist, wird automatisch allen Gruppenmitgliedern zugewiesen.
Eine Entität, die durch Verweisen auf eine Gruppe aus einem verknüpften Verzeichnis in Ihrer Orchestrator-Instanz erstellt wird. Alle Mitglieder der Gruppe sind potenzielle Benutzer des Orchestrators. Alle Rollen, die einer Gruppe zugewiesen sind, werden an die Benutzer dieser Gruppe vererbt – sowohl an automatisch bereitgestellte als auch an einzeln hinzugefügte Benutzer.
- Ein Benutzer, der mehreren Gruppen angehört, erbt die Rollen von allen.
- Ein Benutzer, der mehreren Gruppen angehört und dem auch explizit Rollen gewährt wurden, hat die Vereinigung aller Rollen, die geerbt und explizit zugewiesen wurden.
Die Verwendung von Verzeichnisgruppen ermöglicht den automatischen Zugriff mit den Gruppenberechtigungen, basierend darauf, dass Benutzer der Verzeichnisgruppe hinzugefügt oder daraus entfernt werden (z. B. beim Wechseln von Abteilungen), ohne dass Benutzerberechtigungen einzeln verwaltet werden müssen.
Beispiel
Verzeichnisgruppen |
Geerbte Rechte |
Explizite Rechte |
---|---|---|
Gruppe X mit Zugriffsrechten X und Gruppe Y mit Zugriffsrechten Y hinzugefügt. |
John Smith gehört zu Gruppe X und Y. Er meldet sich beim Orchestrator an. Sein Benutzer hat automatisch die folgenden Rechte: X, Y. |
Zusätzlich zu den Sätzen X und Y erhält John auch explizit den Satz Z. John hat nun folgende Rechte: X, Y, Z. Wenn die Gruppen X und Y gelöscht werden, bleibt John der Satz Z. |
- Sie benötigen keinen expliziten Benutzereintrag, um sich beim Orchestrator anzumelden, wenn Sie zu einer Gruppe gehören, die dem Orchestrator hinzugefügt wurde (Schritt 1 – Abschnitt Verhalten).
- Geerbte Zugriffsrechte sind von der zugeordneten Verzeichnisgruppe abhängig. Wenn das Verzeichnis gelöscht wird, werden auch vererbte Zugriffsrechte gelöscht.
- Explizit festgelegte Zugriffsrechte sind unabhängig von der Verzeichnisgruppe. Sie bleiben zwischen Sitzungen bestehen, unabhängig vom Status der Gruppe.
Roboterkonten sind hilfreich, wenn Sie Unattended-Prozesse im Back-Office ausführen müssen, die nicht in der Verantwortung eines bestimmten Benutzers liegen sollten. Dies sind unsere RPA-spezifischen Äquivalente von Dienstkonten. Ähnlich wie die Konten, die Windows-Dienste als Anwendungsidentitäten im OAuth-Modell ausführen, sind sie eine Identität ohne Benutzer, die zur Ausführung von Unattended-Prozessen verwendet wird.
Arbeiten mit Roboterkonten
Roboterkonten verhalten sich im Bezug auf Berechtigungen wie Benutzerkonten. Im UiPath Orchestrator können Sie Roboterkonten hinzufügen und Berechtigungen dafür auf die gleiche Weise wie bei jedem anderen Konto konfigurieren.
Die einzigen Unterschiede im Vergleich zu Benutzerkonten sind:
- Bei Roboterkonten sind keine interaktiven Prozesskonfigurationen zulässig.
- Zum Erstellen eines Roboterkontos ist keine E-Mail-Adresse erforderlich.
Sie können Roboterkonten auf die gleiche Weise finden und mit ihnen arbeiten wie bei Benutzerkonten:
-
Organisationsadministratoren können Roboterkonten auf der Seite „Administrator“ > „Konten und Gruppen“ erstellen und verwalten – nicht aber auf der Registerkarte Benutzer, sondern auf der dedizierten Registerkarte Roboterkonten.
Roboterkonten können auch in Gruppen aufgenommen und als Teil der Gruppe verwaltet werden.
- Bei der Zuweisung von Rollen im Orchestrator werden bei der Suche nach Konten Benutzer, Gruppen und auch Roboterkonten zur Auswahl angezeigt.
Wenn Sie bei klassischen Ordnern einen Roboter manuell im Orchestrator bereitstellen, wird ein Roboter Die Entität wird automatisch erstellt und kann auf der Registerkarte Roboter angezeigt werden.
Roboterbenutzern wird standardmäßig die Roboterrolle zugewiesen.
Ein Dienstkonto ist ein nicht menschliches Konto, das verwendet wird, um einen Sicherheitskontext für die Ausführung von Workloads bereitzustellen, bei denen kein menschliches Konto vorhanden ist, z. B. Server-zu-Server-Authentifizierungen. In diesen Fällen übernimmt der Orchestrator die Identität des Dienstkontos.
Pro Orchestrator-Instanz wird nur ein Dienstkonto erstellt. Es ist in der Benutzeroberfläche nicht sichtbar und kann nur in Datenbanktabellen identifiziert werden.
Mit diesem Kontotyp sind keine Authentifizierungsinformationen verbunden, und daher kann er sich nicht interaktiv über Browser oder Cookies anmelden.
Wir empfehlen, das Dienstkonto nicht zu deaktivieren oder zu löschen, da dies direkte Auswirkungen auf die ausgeführten Workloads hat.