Verwalten · D1 · 6 Stufen

Rollen, Gruppen und Rechte

Track D ist der Betreiber-Track. In D1 richtest du als Org-Admin der Muster GmbH die Governance ein — wer in der Organisation was darf, vom Rollenmodell bis zum Offboarding.

Was du in diesem Tutorial einrichtest

Du bist Org-Admin der Muster GmbH und vergibst Rechte rund um den in Track C gebauten Helpdesk-Assistenten. Du legst die Gruppe „Helpdesk-Team" an, erteilst ihr das Nutzungsrecht am Agenten und behältst Bearbeitungsrechte einem kleinen Kreis vor. Statt „Das solltest du können"-Checks gibt es hier Verwaltungs- und Prüfschritte mit echten Admin-Reitern und -Dialogen, gezeigt als Konfigurations-Mockups.

Voraussetzung: Für agentbezogene Rechte reichen je nach Instanz Agent-Admin-Rechte; für Benutzer-/Gruppenverwaltung, 2FA und Verzeichnis-Sync brauchst du Org-Admin oder höher (gegen Instanz prüfen). Track B wird zum Verständnis empfohlen, A für den Bedienkontext. Die organisationsweite Benutzer- und Gruppenverwaltung und der Microsoft-Konnektor in voller Tiefe folgen in D2.

Quellenregel: Maßgeblich ist das Referenzkapitel Administrator-Handbuch Kap. 1 (Rollen und Rechte, 1.1–1.6). Rollen-Wertstufen, der Zuschnitt von „Service-Administrator" sowie Feld- und Reiter-Namen sind instanz- und versionsabhängig — sie sind als „gegen Instanz prüfen" markiert. Alle Gruppen- und Agentennamen sind Demo-Werte, keine echten Stammdaten oder Secrets.
Verwaltung ist risikobehaftet: Du arbeitest hier an den Hebeln, die über Zugriff entscheiden. Zu großzügige Admin-Vergabe und ein lückenhaftes Offboarding sind die zwei häufigsten Fehler — sie ziehen sich als Warnhinweise durch alle Stufen.

Quellen und Stand

Geprüft gegen das AuxData-Administrator-Handbuch (Stand Juni 2026), Kapitel 1 (Rollen und Rechte, 1.1–1.6). Der Verzeichnis-Sync verweist auf Kapitel 9 (Details in D2). Rollen-Wertstufen, die Spalte „Service-Administrator", Reiter- und Feldnamen sowie Konnektor-Scopes sind instanzabhängig — „gegen Instanz prüfen".

Stufe 1 von 6

Das Rollenmodell

Drei Bausteine — und wer auf der Plattform was darf.

1Drei Bausteine

AuxData.ai setzt ein hierarchisches Rechte-System aus drei Bausteinen ein. Sie sind der rote Faden der Stufen 1–4. (AH 1)

Benutzer-Rollen
Berechtigung auf Plattform-Ebene — im Benutzerprofil hinterlegt.
Gruppen
Sammlungen von Benutzern, die gemeinsame Rechte erben (Stufe 2).
Objektbezogene Rechte
pro Agent bzw. Ressource — nutzen vs. bearbeiten (Stufe 3).
Hintergrund: Die Authentifizierung läuft über Keycloak; jeder API-Aufruf trägt einen JWT-Token mit Benutzer-ID, Organisations-ID, Rolle, Gruppen und Ablaufdatum. Die Rolle wird im Feld Rolle in edituser.html hinterlegt und im Frontend als Schwellenwert (Rollen-Wert) abgefragt — höhere Werte schließen die Rechte niedrigerer Werte ein. (AH 1, 1.1)
Reiter Anwender der Benutzerverwaltung (offizielle Abbildung aus dem Admin-Handbuch)
Offizielle Abbildung aus dem Admin-Handbuch (Kap. 9) — der Reiter „Anwender": Benutzer der Organisation.

2Die vier Plattform-Rollen

Vier Rollen aus AH 1.1, jeweils mit dem, was sie dürfen:

Anwender
Services und Chatbots nutzen; keine organisations-administrativen Zugriffe.
Agent-Administrator
Agenten konfigurieren, Wissensdatenbanken pflegen, Services und Workflows erstellen.
Org-Admin / Administrator
zusätzlich: Organisation bearbeiten, Benutzer und Gruppen verwalten, LLM-Provider konfigurieren, HTTP-/Function-/MCP-Services anlegen, Marktplatz-Agenten installieren.
Plattform-Manager
Partner- und Distributions-Rechte; laut Handbuch nicht Gegenstand des Admin-Handbuchs — hier nur der Vollständigkeit halber genannt.
Gegen Instanz prüfen: Die genauen Rollen-Wertstufen (0/1/2/3) und die Zuordnung der Bezeichnungen sind in der Quelle nur tabellarisch angedeutet und können je Instanz und Version abweichen. Für D1 zählt die Bedeutung der Rollen, nicht die Zahl. (AH 1.1)
Service-Administrator einordnen: Die Rechte-Matrix in AH 1.4 führt zusätzlich eine Spalte „Service-Administrator". D1 übernimmt sie als Matrix-Spalte, behandelt sie aber nicht als universelle Zielrolle für alle Organisationen — Zuschnitt und Sichtbarkeit bitte in der konkreten Instanz prüfen.
✎ Übung: Ordne diese drei Personen einer Rolle zu — (a) eine Mitarbeiterin, die nur mit dem Helpdesk-Assistenten chattet, (b) ein Builder, der Agenten und Wissensdatenbanken pflegt, (c) du selbst als Org-Admin. (a Anwender, b Agent-Administrator, c Org-Admin — AH 1.1)

✓ Das hast du eingerichtet / geprüft

Stufe 2 von 6

Gruppen

Der effizienteste Weg, einem Kreis von Personen Rechte zu geben.

1Warum Gruppen?

Benutzer können einer oder mehreren Gruppen angehören. Gruppen sind der effizienteste Weg, einem Kreis von Personen Rechte auf denselben Agenten oder dieselbe Ressource zu erteilen — statt jedes Recht einzeln pro Benutzer zu pflegen. (AH 1.2)

BenutzerGruppenEinladungen
Gruppe bearbeiten · usermanagement.html
Gruppenname
Helpdesk-Team
Beschreibung
Support-Mitarbeitende, die den Helpdesk-Assistenten nutzen.
MitgliederDemo-Werte
a.musterb.beispielc.demo+ hinzufügen …
Verzeichnis-Syncaus Azure AD übernommen
aus (Stufe 6)
Echte Benutzerverwaltung: Anwender-Tabelle (ID, Name, E-Mail maskiert, Rolle) mit geöffnetem Dialog „Gruppe erstellen
D1-S01 · Benutzerverwaltung an der Demo-Instanz mit Dialog „Gruppe erstellen" (E-Mail als Demo maskiert)
Reiter Gruppen der Benutzerverwaltung (offizielle Abbildung aus dem Admin-Handbuch)
Offizielle Abbildung aus dem Admin-Handbuch (Kap. 9) — der Reiter „Gruppen" der Benutzerverwaltung.

Erreichbar über Einstellungen → Benutzerverwaltung (usermanagement.html), Panel Gruppen. Die ausführliche Gruppen- und Benutzerverwaltung steht in Kapitel 9 (→ D2). In D1 legen wir die Gruppe nur an, um ihr in Stufe 3 ein Recht zu geben. (AH 1.2)

2Muster aus dem Handbuch

Gruppe „Vertrieb"
Leserecht auf einen Agenten.
Gruppe „IT-Support"
Administrationsrechte auf mehrere Agenten.
Gruppe „Helpdesk-Team"
unsere Demo — später Nutzungsrecht auf „Helpdesk-Assistent" (Stufe 3).
Mitgliedschaften sparsam halten: Wer in eine Gruppe aufgenommen wird, erbt alle Rechte dieser Gruppe. Mitgliedschaften deshalb bewusst und sparsam vergeben — eine Gruppe mit Admin-Rechten ist ein attraktives Ziel und ein Offboarding-Risiko (vertieft in Stufe 6). (AH 1.2)
✎ Übung: Warum legst du für das Helpdesk-Team eine Gruppe an, statt jedem Mitglied das Nutzungsrecht einzeln zu geben? (Gruppen vergeben Rechte gebündelt und sind der effizienteste Weg für einen Personenkreis auf dieselbe Ressource — AH 1.2)

✓ Das hast du eingerichtet / geprüft

Stufe 3 von 6

Objektbezogene Rechte

Nutzen vs. bearbeiten — pro Agent.

1Die Zugriffsliste pro Agent

Zusätzlich zu Rolle und Gruppe gibt es pro Agent eine Zugriffsliste (agentrights.html). Sie kennt zwei Eintragstypen. (AH 1.3)

BerechtigungenBerechtigung hinzufügen
Zugriffsliste · Helpdesk-Assistent · agentrights.html
AnwenderLayer User — darf nutzen
Gruppe: Helpdesk-Team
chatten, Services ausführen.
AdministratorLayer Agent / Organisation — darf bearbeiten
Benutzer: c.demoGruppe: Agent-Admins
Agent bearbeiten, Wissensdatenbank pflegen, Rechte vergeben.
Eintrag vergeben an
BenutzerGruppe

Demo: Gruppe „Helpdesk-Team" als Anwender, ein kleiner Kreis als Administrator. Rechte lassen sich an einzelne Benutzer oder an Gruppen vergeben. (AH 1.3)

2Konfliktregel: das höhere Recht gewinnt

Bei Konflikten gewinnt immer das höhere Recht: Ist ein Benutzer über seine Gruppe „Administrator", behält er das auch dann, wenn er persönlich als „Anwender" eingetragen ist. Konsequenz: Ein versehentliches Admin-Recht über eine Gruppe lässt sich nicht durch einen niedrigeren Einzeleintrag „zurücknehmen" — die Gruppenzugehörigkeit selbst muss geprüft werden. (AH 1.3)

Hinweis: Auch HTTP-Services, Funktionen und Services können eigene Rechte tragen und haben je nach Konfiguration interne bzw. organisationsweite Sichtbarkeit. Die Detailpflege folgt in späteren Tracks und Tutorials. (AH 1.3)

✎ Übung: Das Helpdesk-Team soll den Assistenten nur nutzen, nicht konfigurieren. Welcher Eintragstyp passt, und wo trägst du ihn ein? (Anwender/Layer User auf agentrights.html, vergeben an die Gruppe „Helpdesk-Team" — AH 1.3)

✓ Das hast du eingerichtet / geprüft

Stufe 4 von 6

Die Rechte-Matrix & Least-Privilege

Wer darf was — und wie wenig reicht wirklich?

1Wer darf was?

Die Matrix stellt Aktionen den Rollen gegenüber und ist die Prüfgrundlage für Least-Privilege: jede Person nur so viel, wie sie wirklich braucht. (AH 1.4)

Rechte-Matrix · Auszug nach AH 1.4 · ✔ = darf
AktionAnwenderAgent-AdminOrg-AdminService-Admin
Chat mit Agent / AI-Service ausführen✔✔✔✔
Eigene KB pflegen✔✔✔✔
Agent anlegen / Agent-KB pflegen✔✔✔
AI-Service / Workflow anlegen✔✔✔
Rechte auf Agenten vergeben✔✔✔
Benutzer anlegen / ändern✔✔
Gruppe anlegen✔*✔✔
LLM-Provider konfigurieren✔✔
HTTP-/Function-/MCP-Service anlegen✔✔
Organisations-Settings ändern✔✔
Feedback organisationsweit lesen✔✔

(*) „Gruppe anlegen" beim Agent-Admin laut Handbuch nur für den Agenten, dessen Administrator man ist. (AH 1.4)

2Least-Privilege in der Praxis

Zu großzügige Admin-Vergabe vermeiden: Die Aktionen Benutzer anlegen/ändern, LLM-Provider konfigurieren, Organisations-Settings ändern sind echte Org-Admin-Hebel. Wer Personen pauschal Org-Admin gibt, vergibt all das mit — das verletzt Least-Privilege. Für reine Builder reicht Agent-Administrator; für reine Nutzer die Rolle Anwender plus Gruppen-Nutzungsrecht. (AH 1.4)
Gegen Instanz prüfen: Die genaue Spalten- und Zeilenbelegung und die Rolle „Service-Administrator" sind aus der Handbuch-Tabelle übernommen, aber instanzabhängig. Nutze die Spalte als Warnsignal: Wer Service-Admin bekommt, kann je nach Instanz ähnlich weitreichende Verwaltungsrechte haben wie ein Org-Admin. (AH 1.4)
✎ Übung: Eine Kollegin soll Benutzerkonten anlegen dürfen, aber keine LLM-Provider berühren. Geht das mit einer einzigen Standardrolle sauber — und was ist hier die Least-Privilege-Frage? („Benutzer anlegen" sitzt laut Matrix erst auf Org-Admin-Ebene, die LLM-Provider mitbringt; deshalb bewusst abwägen statt pauschal Org-Admin zu vergeben — AH 1.4)

✓ Das hast du eingerichtet / geprüft

Stufe 5 von 6

Zwei-Faktor & Login-Sicherheit

2FA organisationsweit erzwingen.

12FA auf Organisations-Ebene

Auf Organisations-Ebene kann 2FA erzwungen werden: die Checkbox „2-Faktor-Authentifizierung erforderlich" in editorg.html. Ist sie gesetzt, werden Benutzer beim ersten Login zur Einrichtung einer TOTP-App gezwungen, bevor sie die Anwendung erreichen. (AH 1.5)

AllgemeinSicherheitMicrosoft Konnektor
Organisation bearbeiten · Muster GmbH · editorg.html
2-Faktor-Authentifizierung erforderlichTOTP-App beim ersten Login erzwingen
an
Geltungsbereich
alle Benutzer der Organisation

2Empfehlung & Grenzen

Plattform-weit empfohlen: 2FA wird unabhängig von der Organisations-Pflicht empfohlen, insbesondere für alle Konten mit Rolle ≥ 2 (also Org-Admin und höher) — das sind die Konten mit den weitreichendsten Rechten aus Stufe 4. (AH 1.5)
Nicht erfinden: Weitergehende Login- und Abmelde-Details über das hier Genannte hinaus stehen nicht in Kapitel 1. Bei Bedarf gegen Instanz bzw. Keycloak-Konfiguration prüfen.
✎ Übung: Die Muster GmbH will 2FA verpflichtend machen. Wo setzt du das, und was passiert beim nächsten Login eines bestehenden Benutzers? (Checkbox „2-Faktor-Authentifizierung erforderlich" in editorg.html; beim ersten Login Zwang zur TOTP-Einrichtung vor Zugriff auf die Anwendung — AH 1.5)

✓ Das hast du eingerichtet / geprüft

Stufe 6 von 6

Verzeichnis-Sync & Offboarding

Microsoft Entra / Azure AD — und das Offboarding-Leck.

1Der Microsoft-Konnektor

Im Organisations-Editor → Reiter „Microsoft Konnektor" konfigurierst du die automatische Benutzer-Synchronisation über Microsoft Graph. (AH 1.6, Details Kap. 9)

AllgemeinSicherheitMicrosoft Konnektor
Verzeichnis-Sync · Microsoft Entra / Azure AD
Neu angelegte Azure-AD-Benutzer anlegen
an
Entfernte Benutzer deaktivierenschließt das Offboarding-Leck
an
Gruppenmitgliedschaften synchronisierenoptional
optional
Volle Konfiguration
Kapitel 9 / Tutorial D2

Der Prozess legt neu angelegte Azure-AD-Benutzer in AuxData.ai an, deaktiviert entfernte Benutzer und synchronisiert optional Gruppenmitgliedschaften. D1 zeigt nur den Einstieg — die volle Konfiguration behandelt Kapitel 9 / Tutorial D2. (AH 1.6 verweist explizit auf Kap. 9)

2Das Offboarding-Risiko

Offboarding-Leck: Ohne Sync (oder bei nur teilweisem Sync) bleiben Konten ausgeschiedener Personen aktiv — ein klassisches Offboarding-Leck. Der Sync deaktiviert entfernte Benutzer automatisch und schließt diese Lücke. Prüfe deshalb, ob Onboarding und Offboarding über den Konnektor laufen — und ob Gruppenmitgliedschaften mitsynchronisiert werden, sonst greifen die Rechte aus Stufe 2/3 nicht wie erwartet. (AH 1.6)
Gegen Instanz prüfen: Reiter-Name, Scope-Umfang und ob der Sync aktiv ist, hängen von der Instanz ab — vor Verlass darauf in der echten Organisation gegenprüfen (Details D2). (AH 1.6)

Governance eingerichtet!

Du kennst jetzt das Rollenmodell der Muster GmbH, hast die Gruppe „Helpdesk-Team" mit dem richtigen Recht am Helpdesk-Assistenten ausgestattet, die Rechte-Matrix gegen Least-Privilege geprüft, 2FA erzwungen und das Offboarding-Risiko über den Verzeichnis-Sync verstanden. Mach das Quiz und geh dann weiter zu D2 — Organisation und Microsoft-Konnektor, wo die Benutzer- und Gruppenverwaltung und der Konnektor in voller Tiefe folgen (Kap. 9).

✎ Übung: Eine Person verlässt die Muster GmbH und wird in Azure AD entfernt. Was passiert mit ihrem AuxData-Konto bei aktivem Sync — und welche Lücke entsteht ohne Sync? (Mit Sync wird das Konto automatisch deaktiviert; ohne Sync bleibt es aktiv und ist eine Offboarding-Lücke — AH 1.6)

✓ Das hast du eingerichtet / geprüft

Kurz-Quiz

Sitzen Rollen, Gruppen & Rechte?

6 szenariobasierte Fragen aus den Stufen 1–6. Kein Zertifikat — zur Selbstkontrolle. Beliebig oft wiederholbar.

Frage 1 von 6
Lade Frage…