Users & Tenants¶
Admin → Benutzer & Rechte — Reiter Benutzer, Rollen, Teams und Tenants. Benutzer, Teams, Tenants und Tenant-Gruppen verwalten nur Super-Admins.
Tenants¶
Ein Tenant ist die Mandanten-Trennlinie — typisch ein Kunde oder eine Abteilung.
Anlegen¶
Admin → Benutzer & Rechte → Tenants → Tenant anlegen:
| Feld | Bedeutung |
|---|---|
| Name | Anzeigename |
| Slug | Kurzname, eindeutig (wird aus dem Namen vorgeschlagen) |
Tenant-Anlage ist eine Super-Admin-Funktion — sie ist bewusst nicht über eine eigene delegierbare Permission an andere Rollen vergebbar. Ein neuer Tenant übernimmt den Instanz-Standard, ob der Vesana-Server bei ihm selbst Checks ausführen darf (siehe Aktiver Collector).
Ein Klick auf einen Tenant klappt seine Details auf: Hosts, Collectors, Standorte, Zugangsdaten und die Alert-Gruppierung des Tenants.
Tenant kopieren¶
Rechtsklick auf einen Tenant → Tenant kopieren legt einen neuen Tenant mit allen Hosts und Services an (ohne Messwerte und Verlauf). Check-Einstellungen und Overrides werden übernommen, nicht aber SNMP-Communities und Check-Geheimnisse — die trägst du im neuen Tenant neu ein. Welche Angaben ausgelassen wurden, steht im Audit-Eintrag tenant_copy. Eine Kopie zählt gegen dieselbe Lizenz-Grenze wie eine Neuanlage.
Tenant deaktivieren¶
Deaktivieren im Rechtsklick-Menü legt einen Tenant still, ohne ihn zu löschen. Beim erneuten Aktivieren prüft Vesana die Tenant-Grenze der Lizenz.
Daten pro Tenant¶
Nach Anlage hat ein Tenant:
- 0 Hosts
- Default-Alert-Channel-Templates (leer)
- Audit-Log
Du kannst direkt Hosts anlegen, Profile sind tenant-übergreifend (Builtins) verfügbar.
Grenzen je Tenant¶
Ein Tenant ist standardmäßig unbegrenzt — es gilt nur die Hostzahl der Lizenz. Wer mehreren Kunden eine feste Obergrenze geben will (z. B. „Kunde A darf 50 Geräte“), setzt sie unter Admin → System → Lizenz → Grenzen je Tenant (zugeklappt, nur Super-Admins). Pro Tenant gibt es drei Felder: Hosts, Checks, Collectors.
- Leer = unbegrenzt, 0 = keine neuen mehr, sonst die Obergrenze.
- Eine Grenze verhindert nur neue Einträge; was schon da ist, bleibt.
- Neben einem begrenzten Feld steht, wie viel gerade belegt ist.
- Wird die Grenze erreicht, antwortet Vesana mit einer Meldung, die diesen Ort nennt.
- Jede Änderung steht im Audit-Log (
tenant_limits_update).
Bis v1.9.452 galt fest 100 Hosts / 1000 Checks / 5 Collectors je Tenant, ohne dass man das ändern konnte.
Tenant-Gruppen¶
Optional, für größere Umgebungen: Tenants → Gruppen verwalten (nur Super-Admins) legt Gruppen an, z. B. „Kunden Nord". Über das Rechtsklick-Menü eines Tenants → In Gruppe verschieben ordnest du ihn zu; ein Tenant gehört zu höchstens einer Gruppe. Sobald es Gruppen gibt, zeigt die Tenants-Liste die Tenants nach Gruppen geordnet.
Eine Gruppe kann der Bereich einer Rollen-Zuweisung sein: „Team Technik Nord · Admin · Gruppe Kunden Nord" gilt für jeden Tenant in der Gruppe — auch für einen, den du später hineinlegst. Eine Gruppe, an der noch Zuweisungen hängen, lässt sich nicht löschen.
Tenant löschen¶
Löschen verschiebt den Tenant in den Papierkorb — mit allen Hosts, Services, Alerts und weiteren Objekten (gemeinsame Löschgruppe). Wiederherstellen im Papierkorb holt die ganze Familie zurück. Das Löschen verlangt eine frische Identitätsbestätigung.
Der Dialog fragt, was mit den Agents und Collectors des Tenants passiert:
- Installiert lassen (Standard) — sie ruhen. Wird der Tenant wiederhergestellt, arbeiten sie nach wenigen Minuten von selbst weiter.
- Deinstallieren — sie entfernen sich beim nächsten Kontakt von ihren Geräten (Geräte mit aktiver Lokaler Freigabe lehnen das ab und ruhen). Nach einem Wiederherstellen müssen sie neu installiert werden.
Endgültig gelöscht wird nach 30 Tagen automatisch oder vorher im Papierkorb. Dabei verschwinden auch gespeicherte Zugangsdaten, Notizen und offene Benachrichtigungen des Tenants.
Cross-Tenant-Sichtbarkeit¶
Jeder User hat ein Feld Tenant-Zugriff: entweder Alle (alle Tenants, auch künftige) oder eine Auswahl konkreter Tenants. Seine Grundrolle gilt in genau diesen Tenants. Dazu kommen Tenants, für die er über ein Team oder eine direkte Zuweisung Rechte hat — dort mit der jeweils zugewiesenen Rolle. Zwischen seinen Tenants wechselt er über die Tenant-Auswahl.
Ein Operator kann so in mehreren Tenants Zugriff haben, ohne Super-Admin zu sein — und mit Zuweisungen auch in verschiedenen Tenants verschiedene Rollen.
Users¶
Anlegen¶
Admin → Benutzer & Rechte → Benutzer → Benutzer anlegen (nur Super-Admins, mit Identitätsbestätigung):
| Feld | Bedeutung |
|---|---|
| Benutzername | Login — ein einfacher Name wie admin reicht, eine E-Mail-Adresse ist nicht nötig (Vesana verschickt keine Mails an Benutzer) |
| Anzeigename | Name in der Oberfläche |
| Passwort | wird beim Anlegen gesetzt; der Benutzer ändert es danach selbst (Einstellungen → Profil → Passwort ändern) |
| Rolle | Grundrolle — eingebaute oder eigene Rolle |
| Tenant-Zugriff | Alle oder eine Auswahl konkreter Tenants |
Benutzer kopieren (Zeilen-Aktion) übernimmt Rolle und Tenant-Zugriff; Benutzername, Name und Passwort vergibst du neu.
Konten aus SSO oder Active Directory legt Vesana bei der ersten Anmeldung selbst an; die Liste kennzeichnet sie. Für ein Domänenkonto gilt das Passwort aus dem Verzeichnis — ein in Vesana gesetztes Passwort ist nur der Notausgang, solange das Verzeichnis nicht erreichbar ist.
Passwort vergessen¶
Es gibt keinen Reset-Link per E-Mail. Ein Admin setzt das Passwort in der Benutzerzeile neu — dabei werden alle Sitzungen des Benutzers beendet, und er meldet sich mit dem neuen Passwort an.
Aktionen in der Benutzerzeile¶
Jede Aktion steht als Symbol rechts in der Zeile und im Rechtsklick-Menü: Bearbeiten, Kopieren, Passwort setzen, Rechte & Teams (siehe Rollen-Zuweisung), Script-Rechte (auf welchen Hosts der Benutzer script-fähige Checks anlegen oder ändern darf; ohne eigene Einstellung: Admin auf allen seinen Tenants, jede andere Rolle nirgends — siehe Scripts), Alle Sitzungen abmelden (fragt nach und meldet zurück, wie viele Sitzungen betroffen waren), 2FA zurücksetzen (siehe 2FA), Deaktivieren/Aktivieren, Löschen. Nicht mögliche Aktionen sind ausgegraut und nennen den Grund. Die Liste zeigt außerdem, wer TOTP oder Passkeys eingerichtet hat. Ein gelöschter Benutzer gibt seinen Namen sofort wieder frei — der Papierkorb-Eintrag trägt das Löschdatum im Namen.
Account aktiv / inaktiv¶
Statt User zu löschen, Deaktivieren. Vorteile:
- Audit-Log behält den User-Verweis
- Re-Aktivierung möglich
- Seine Dashboards bleiben ihm zugeordnet, Freigaben an andere bleiben bestehen
Ein deaktivierter User kann sich nicht anmelden; laufende Sitzungen und API-Zugriffe enden sofort.
Soft-Delete¶
Löschen verschiebt den Benutzer in den Papierkorb; dort lässt er sich wiederherstellen oder endgültig löschen. Das Audit-Log behält den User-Verweis — dass dieser User existiert hat.
Ein gelöschter Benutzer verliert seine Sitzungen und seinen API-Zugriff sofort. Das Anmelde-Token eines endgültig gelöschten Kontos wird auch später nicht wieder gültig. Gelöschte Benutzer lassen sich nicht mehr bearbeiten, reaktivieren oder per Passwort-/2FA-Reset ändern.
User wechseln Tenants?¶
Nicht als „Umzug" — stattdessen den Tenant-Zugriff des Users anpassen: neuen Tenant zur Auswahl hinzufügen, alten entfernen. Unterschiedliche Rollen je Tenant brauchen keinen zweiten Benutzer mehr, sondern eine Zuweisung.
Eigene Einstellungen¶
Jeder Benutzer unter Einstellungen (Avatar-Menü):
- Profil — Profilbild, Benutzername (nur lesen), Anzeigename, Passwort ändern (bei Domänenkonten im Verzeichnis statt in Vesana)
- 2FA — Authenticator-App, Passkeys, Backup-Codes — siehe 2FA
- Sitzungen — angemeldete Geräte, einzeln oder überall sonst abmelden — siehe Sitzungen
- Push — Push-Benachrichtigungen auf diesem Gerät
- Präferenzen — Hell/Dunkel, Theme, Listen-Darstellung, Sprache, KI-Assistent und KI-Analyse anzeigen, Aktualisierungs-Intervall
Persönliche API-Schlüssel gibt es nicht. Skripte melden sich über die Anmelde-API mit einem Benutzerkonto an — siehe API-Authentifizierung.
Permissions vs. Tenant-Scope¶
Permissions gelten je Tenant: ein User mit hosts.create kann nur in den Tenants Hosts anlegen, in denen eine seiner Rollen dieses Recht enthält. Benutzer-, Team- und Tenant-Verwaltung bleiben Super-Admin-Funktionen; Rollen bearbeiten darf außerdem, wer users.edit_role in allen Tenants hat.
Details: Rollen & Permissions.