Kontotypen

Der UiPath Identity Server speichert lokale Konten und die ihnen zugewiesenen Rollen, überprüft aber auch alle Verzeichniskonten, die im Orchestrator verwendet werden.

Lokaler Benutzer

Ein Konto, das vom Identity Server ü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.

Verzeichnisbenutzer

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 in Identity Server und Orchestrator verwaltet, während der externe Verzeichnisadministrator kontospezifische Attribute (Name, E-Mail, Verzeichnisgruppenmitgliedschaft) verwaltet.

Es gibt zwei Möglichkeiten, einem Verzeichnisbenutzer Zugriff auf den Orchestrator zu gewähren:

1. Indem wir dem Verzeichnisbenutzer im Orchestrator Rollen zuweisen, bezeichnen wir ihn als individuell hinzugefügten Benutzer.
2. Durch die Anmeldung mit einem Konto, das zu einer Verzeichnisgruppe gehört, die zuvor zum Orchestrator hinzugefügt wurde – wir bezeichnen dies als automatisch bereitgestellten Benutzer. Weitere Informationen finden Sie unter Über Benutzer.

Unabhängig von ihrem Typ erben Verzeichnisbenutzer immer Rollen von den Gruppen, denen sie angehören, wenn sie im Orchestrator vorhanden sind.

Lokale Gruppe

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.

Verzeichnisgruppe

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.
• 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.

Roboter

Robot-Konten

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:

• Administratoren 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.

Roboterentität (veraltet)

Hinweis: Dies gilt nur für klassische Ordner.

Wenn Sie bei klassischen Ordnern einen Roboter manuell im Orchestrator bereitstellen, wird automatisch eine Roboterentität erstellt, die auf der Registerkarte Roboter angezeigt wird.

Roboterbenutzern wird standardmäßig die Roboterrolle zugewiesen.

Dienstkonto

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.