docs: Anleitungen fuer Kollegen — Anwender, Administration, Betrieb, Entwicklung

Bisher gab es fuer Kollegen keine Dokumentation: im Projekt lagen nur das
CI/CD-Runbook und die Arbeitsanweisungen fuer die Entwicklung. Diese Luecke
schliessen vier Anleitungen plus eine Einstiegsseite unter docs/.

Alle vier wurden gegen den Quelltext geschrieben, nicht aus der Planung
abgeleitet, und anschliessend unabhaengig gegengeprueft: jede zitierte
Beschriftung ist woertlich aus de.json belegt, jede beschriebene Funktion im
Code nachgewiesen, alle Befehle und Pfade gegen die echten Compose-Dateien,
Dockerfiles und package.json-Skripte verifiziert. Die Gegenpruefung fand keine
falsche Aussage.

Die Einstiegsseite hebt die drei Punkte hervor, die in der Praxis am meisten
Zeit gekostet haben: Anmeldung ueber den Benutzernamen statt der E-Mail,
der Unterschied zwischen aktiviert und freigegeben, und dass ein blosses
'up -d' die laufenden Container nicht ersetzt.

Nebenbefund beim Schreiben des Betriebshandbuchs, als #17 im Ledger erfasst:
user-files/ ist in keiner Compose-Datei als Volume eingebunden — hochgeladene
Profilbilder und DKV-Exporte ueberleben kein --force-recreate. Noch ohne
Schaden, da bisher kein Nutzer ein Profilbild hinterlegt hat.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU

docs/anleitung-administration.md

@@ -0,0 +1,240 @@
+<!-- generated-by: gsd-doc-writer -->
+# Tessera – Administrationshandbuch
+
+Dieses Handbuch richtet sich an Kolleginnen und Kollegen, die Tessera für ihre Organisation konfigurieren: Benutzer und Gruppen verwalten, die Anbindung an das Active Directory (AD) betreuen, Module freischalten und den Mailversand einrichten. Es setzt keine Programmierkenntnisse voraus, aber Grundwissen über AD-Gruppen, LDAP und SMTP-Server.
+
+## Inhaltsverzeichnis
+
+1. [Rollen und was sie dürfen](#1-rollen-und-was-sie-dürfen)
+2. [Benutzerverwaltung](#2-benutzerverwaltung)
+3. [Gruppen](#3-gruppen)
+4. [AD-/LDAP-Anbindung](#4-ad--ldap-anbindung)
+5. [Modulverwaltung und Freigaben-Matrix](#5-modulverwaltung-und-freigaben-matrix)
+6. [SMTP](#6-smtp)
+7. [Mandanten](#7-mandanten)
+8. [Fehlersuche für Administratoren](#8-fehlersuche-für-administratoren)
+
+---
+
+## 1. Rollen und was sie dürfen
+
+Tessera kennt drei Rollen:
+
+| Rolle | Anzeige im Header | Was sie zusätzlich zu USER darf |
+|---|---|---|
+| **USER** | Benutzer | Zugriff nur auf Module, die ihm direkt oder über eine Gruppe freigegeben wurden. Sieht keinen Administrationsbereich. |
+| **ADMIN** | Admin | Voller Zugriff auf den Administrationsbereich des **eigenen** Mandanten: Benutzer, Gruppen, LDAP, SMTP, Module und die Freigaben-Matrix. Sieht und ändert nur Benutzer/Daten des eigenen Mandanten. |
+| **SUPER_ADMIN** | Super-Admin | Alles, was ADMIN darf, zusätzlich mandantenübergreifend (sieht alle Benutzer aller Mandanten) sowie exklusiv: die Mandantenverwaltung unter „Mandanten“. Kann als einzige Rolle die Rolle SUPER_ADMIN an einen anderen Benutzer vergeben. |
+
+Wichtige Details, die im Code tatsächlich so umgesetzt sind:
+
+- Der Menüpunkt „Administrator“ im Header erscheint nur für ADMIN und SUPER_ADMIN. Ein Benutzer mit der Rolle USER hat keinen sichtbaren Einstiegspunkt in den Administrationsbereich.
+- Innerhalb des Administrationsbereichs ist „Mandanten“ der einzige Navigationspunkt, der ausschließlich für SUPER_ADMIN sichtbar ist; alle anderen Punkte (Benutzer, Module, LDAP, SMTP, Gruppen) sind für ADMIN und SUPER_ADMIN gleichermaßen erreichbar.
+- **ADMIN und SUPER_ADMIN haben immer Zugriff auf alle für den Mandanten aktivierten Module** – unabhängig von der Freigaben-Matrix (siehe Kapitel 5). Die Matrix regelt ausschließlich, welche Module ein Benutzer mit der Rolle USER sehen darf.
+- Ein ADMIN kann einem Benutzer nicht die Rolle SUPER_ADMIN zuweisen – weder beim Anlegen noch beim Bearbeiten. Nur ein SUPER_ADMIN darf das.
+
+## 2. Benutzerverwaltung
+
+Der Bereich **Administrator → Benutzer** zeigt eine Tabelle mit Benutzername, E-Mail, Anzeigename, Rolle und Status. Ein ADMIN sieht dabei ausschließlich die Benutzer des eigenen Mandanten, ein SUPER_ADMIN sieht alle.
+
+### Benutzer anlegen
+
+Über „Benutzer erstellen“ öffnet sich ein Formular mit den Feldern Benutzername, E-Mail, Passwort (mindestens 8 Zeichen), Anzeigename und Rolle. Bei der manuellen Anlage sind Benutzername, E-Mail und Passwort Pflichtfelder. Ein ADMIN kann in der Rollen-Auswahl nur USER oder ADMIN wählen; die Option SUPER_ADMIN erscheint ausschließlich, wenn der eingeloggte Benutzer selbst SUPER_ADMIN ist.
+
+Ein neu angelegter Benutzer wird automatisch Mitglied der als **Standardgruppe** markierten Gruppe (siehe Kapitel 3) – dieser Schritt läuft unsichtbar im Hintergrund, sobald das Konto erstellt wird.
+
+### Benutzer bearbeiten
+
+Beim Bearbeiten lassen sich Benutzername, E-Mail, Anzeigename und Rolle ändern; das Passwortfeld ist optional und wird nur überschrieben, wenn ein neuer Wert eingegeben wird.
+
+### Lokale vs. verzeichnisgeführte Konten
+
+Ein Konto, das über die AD-Anbindung importiert oder synchronisiert wurde, hat kein lokales Passwort – die Anmeldung läuft ausschließlich über eine Prüfung gegen das Verzeichnis (siehe Kapitel 4). Konten, die über das Formular „Benutzer erstellen“ manuell angelegt wurden, haben ein lokales Passwort und melden sich unabhängig von jeder LDAP-Konfiguration an.
+
+Seit Kurzem ist die E-Mail-Adresse eines Benutzers **optional**: Wenn beim Import eine Adresse bereits einem anderen Konto gehört, wird das Konto trotzdem angelegt bzw. aktualisiert – nur eben ohne diese Adresse. Anmeldung und Zugriff funktionieren für ein solches Konto normal, lediglich Benachrichtigungen per E-Mail (z. B. Passwort-Reset) erreichen es nicht. In der Tabelle wird eine fehlende Adresse als „–“ angezeigt. Bei der manuellen Anlage über das Formular ist eine E-Mail-Adresse weiterhin Pflicht.
+
+### Deaktivieren und Löschen
+
+Die Benutzerliste zeigt einen Status „Aktiv“/„Inaktiv“ an, dieser lässt sich aber **nicht** über einen Schalter im Formular umschalten – im Bearbeiten-Dialog gibt es dafür kein Feld. Ein Konto wird auf zwei Wegen inaktiv:
+
+- automatisch durch die LDAP-Synchronisation, wenn der zugehörige Verzeichniseintrag nicht mehr gefunden wird (siehe Kapitel 4, Abschnitt Synchronisation);
+- durch den Button „Benutzer löschen“ in der Tabelle – dieser löscht den Benutzer jedoch **endgültig** aus der Datenbank, es handelt sich nicht um ein reversibles Deaktivieren.
+
+Der eigene Account lässt sich nicht löschen; der Löschen-Button ist für die eigene Zeile deaktiviert.
+
+### Details zu Gruppen und Modulzugriff
+
+Über den Button „Details“ neben einem Benutzer öffnet sich ein Dialog mit zwei Abschnitten:
+
+- **Gruppenmitgliedschaften** – rein informativ (Chips mit Quelle „LDAP“ oder „Manuell“); Änderungen daran erfolgen ausschließlich unter „Gruppen“.
+- **Modul-Zugriff** – eine Tabelle je aktiviertem Modul mit der Spalte „Über Gruppe(n)“ (zeigt, über welche Gruppenmitgliedschaft(en) der Zugriff vererbt wird) und einer Checkbox „Direkt“, mit der zusätzlich zur Gruppenvererbung ein direkter Zugriff für genau diesen Benutzer gesetzt oder entzogen werden kann.
+
+## 3. Gruppen
+
+Der Bereich **Administrator → Gruppen** verwaltet Gruppen, über die Modulzugriff vergeben wird (siehe Kapitel 5). Es gibt zwei Arten von Gruppen:
+
+- **Manuelle Gruppen**: über „Gruppe erstellen“ mit einem frei wählbaren Namen angelegt. Name und Mitglieder lassen sich jederzeit bearbeiten.
+- **AD-gebundene Gruppen**: entstehen ausschließlich über den Import im LDAP-Bereich (Kapitel 4, „AD-Gruppen importieren“) – sie können nicht über den „Gruppe erstellen“-Dialog angelegt werden. Der Dialog weist bei einer Neuanlage per Hinweistext auf den LDAP-Bereich hin.
+
+Die Tabelle unterscheidet beide Typen über ein Badge in der Spalte „AD-Bindung“ („AD-gebunden“ bzw. „Manuell“).
+
+### Interner Name
+
+Bei einer AD-gebundenen Gruppe ist das Namensfeld gesperrt: Der Name wird bei jeder Synchronisation automatisch mit dem AD-Wert überschrieben. Stattdessen lässt sich ein zusätzliches Feld **„Interner Name“** setzen. Dieser interne Name wird von der Synchronisation **nie** verändert oder überschrieben. Solange er gesetzt ist, zeigt die Oberfläche (Gruppentabelle, Freigaben-Matrix) diesen internen Namen anstelle des AD-Namens an; ist er leer, erscheint stattdessen der AD-Name. Damit lässt sich eine Gruppe intern anders benennen, ohne dass der nächste Sync-Lauf diese Bezeichnung wieder zurücksetzt.
+
+Der AD-DN der Gruppe wird im Bearbeiten-Dialog zur Nachvollziehbarkeit schreibgeschützt mit angezeigt.
+
+### Mitglieder
+
+Über „Mitglieder“ lässt sich pro Gruppe eine Mitgliederliste öffnen. Mitglieder mit Quelle „LDAP“ (durch den AD-Sync eingetragen) lassen sich hier **nicht** manuell entfernen – der Entfernen-Button ist für sie deaktiviert, da diese Mitgliedschaft bei der nächsten Synchronisation ohnehin wieder aus dem AD nachgeführt wird. Manuelle Mitgliedschaften (Quelle „Manuell“) lassen sich jederzeit frei hinzufügen und entfernen.
+
+### Standardgruppe
+
+Genau eine Gruppe pro Mandant kann als **Standardgruppe** markiert werden (Stern-Symbol in der Tabelle). Diese Markierung hat zwei konkrete Auswirkungen:
+
+1. **Jeder neu angelegte Benutzer** – ob manuell oder per LDAP-Import/-Sync – wird automatisch Mitglied dieser Gruppe.
+2. Beim Aktivieren eines Moduls bietet der Dialog „Sofort freigeben“ an, das Modul direkt für die Standardgruppe freizugeben (siehe Kapitel 5).
+
+Wird die Markierung auf eine andere Gruppe umgehängt, geschieht das serverseitig als exklusiver Wechsel: Die vorherige Standardgruppe verliert die Markierung automatisch. Ein Mandant ohne jede Gruppe erhält beim ersten Bedarf automatisch eine Gruppe „Alle Benutzer“ als Standardgruppe – dieser Automatismus greift aber nur, wenn tatsächlich noch keine einzige Gruppe existiert, nicht wenn lediglich keine Gruppe als Standard markiert ist.
+
+### Gruppe löschen
+
+Der Löschen-Dialog zeigt vorab an, wie viele Mitglieder und Modul-Freigaben von der Löschung betroffen sind, und weist darauf hin, dass betroffene Benutzer den Zugriff verlieren, sofern sie ihn nicht anderweitig (direkt oder über eine andere Gruppe) haben. Dies gilt auch für AD-gebundene Gruppen – auch sie lassen sich manuell löschen.
+
+## 4. AD-/LDAP-Anbindung
+
+Der Bereich **Administrator → LDAP** bündelt alles rund um die Anbindung an ein Active Directory bzw. einen LDAP-Verzeichnisdienst. Er ist in mehrere Abschnitte gegliedert.
+
+### Verbindungseinstellungen
+
+| Feld | Bedeutung |
+|---|---|
+| **Server-URL** | Die Adresse des Verzeichnisdienstes, z. B. `ldap://ldap.example.com` oder `ldaps://...` für eine verschlüsselte Verbindung. Pflichtfeld. |
+| **Basis-DN** | Mehrzeiliges Feld – **ein DN pro Zeile**. Die Basis-DN(s) legen den Umfang der Synchronisation fest: Nur was unterhalb dieser DN(s) im Verzeichnis liegt, wird überhaupt betrachtet. Mehrere Zeilen bedeuten mehrere gleichrangige Suchwurzeln. |
+| **Bind-DN** | Der DN, mit dem sich Tessera am Verzeichnis anmeldet, um zu suchen (z. B. `cn=admin,dc=example,dc=com`). Leer gelassen wird ein anonymer Bind versucht. |
+| **Bind-Passwort** | Das Passwort zum Bind-DN. Wird verschlüsselt gespeichert; beim erneuten Öffnen des Formulars wird es nie im Klartext angezeigt oder erneut mitgesendet, solange kein neuer Wert eingetragen wird. |
+| **Suchfilter** | LDAP-Suchfilter für die Benutzersuche, standardmäßig `(objectClass=person)`. |
+| **TLS-Zertifikat nicht prüfen (unsicher)** | Nur relevant bei `ldaps://` mit einem Zertifikat einer internen/selbstsignierten Zertifizierungsstelle (typischer Fehler: „unable to verify the first certificate“). Schaltet die Zertifikatsprüfung ab – nur in vertrauenswürdigen Netzen verwenden. |
+
+Über „Verbindung testen“ lässt sich die Konfiguration prüfen, **bevor** sie gespeichert wird – die aktuell im Formular eingetragenen Werte werden dafür verwendet (ein leeres Bind-Passwort-Feld greift dabei auf das bereits gespeicherte Passwort zurück, falls eine Konfiguration existiert).
+
+### Feld-Zuordnung (LDAP-Feld → Tessera-Feld)
+
+Legt fest, welches LDAP-Attribut auf welches Tessera-Feld gemappt wird. Beim erstmaligen Anlegen der Konfiguration werden automatisch drei Standard-Zuordnungen angelegt, die sich nicht entfernen lassen:
+
+| LDAP-Feld | Tessera-Feld |
+|---|---|
+| `displayName` | Anzeigename |
+| `mail` | E-Mail |
+| `sAMAccountName` | Benutzername |
+
+Zusätzliche, selbst definierte Zuordnungen lassen sich über „Zuordnung hinzufügen“ ergänzen und über „Entfernen“ wieder löschen.
+
+### Import-Filter (Gruppen/OUs)
+
+Eine **zusätzliche, optionale** Einschränkung, unabhängig von der Feld-Zuordnung: Ohne Auswahl werden alle Benutzer unter den konfigurierten Basis-DN(s) synchronisiert. Über „Gruppen/OUs suchen“ lässt sich das Verzeichnis nach Gruppen und Organisationseinheiten durchsuchen; ausgewählte Einträge grenzen die Synchronisation weiter ein. DNs lassen sich auch manuell eintragen. Diese Auswahl muss über „Filter speichern“ separat gesichert werden.
+
+### AD-Gruppen importieren
+
+Legt ausgewählte AD-Gruppen als eigenständige Tessera-Gruppen an. Das ist der **einzige** Weg, eine AD-gebundene Gruppe zu erzeugen (siehe Kapitel 3). Wichtig zu wissen:
+
+- Nach dem Import wird die Gruppe bei jeder weiteren Synchronisation automatisch nachgeführt: Ein Umbenennen der Gruppe im AD wird übernommen, ihre Löschung im AD führt (nach einer zusätzlichen Absicherung gegen bloße Verschiebung außerhalb des konfigurierten Bereichs) auch zur Löschung der Tessera-Gruppe.
+- Bereits importierte Gruppen werden in der Trefferliste als „Bereits importiert“ markiert und lassen sich nicht ein zweites Mal auswählen.
+- Kollidiert der Name der zu importierenden AD-Gruppe mit einer bereits vorhandenen lokalen Gruppe, schlägt der Import für diesen Eintrag fehl; die bestehende lokale Gruppe muss zunächst umbenannt oder mit einem internen Namen versehen werden.
+- Die Mitgliedschaften der importierten Gruppe werden nicht sofort befüllt, sondern erst beim nächsten Sync-Lauf (manuell oder nach Intervall).
+
+### Einzelbenutzer suchen und importieren
+
+Sucht gezielt einzelne AD-Benutzer über einen Freitext (Name, Benutzername oder E-Mail) und importiert nur die ausgewählten Treffer. Bereits vorhandene Benutzer werden als „Bereits importiert“ markiert und übersprungen – es entsteht dadurch kein Doppelimport, auch wenn später eine vollständige Synchronisation über den Import-Filter läuft.
+
+### Benutzer ausschließen (Denylist)
+
+Eine Liste einzelner Benutzernamen, die **nie** importiert werden – typischerweise technische Dienstkonten wie `administrator`, `krbtgt`, `guest` oder `ldap$`. Sie wirkt zusätzlich zum Gruppen-/OU-Filter, also unabhängig davon, ob der Eintrag im gefilterten Suchbereich läge. Die Liste muss über „Ausschlussliste speichern“ gesichert werden.
+
+### Synchronisation
+
+Zwei Zeitpunkte für den Sync-Lauf:
+
+- **Sync-Intervall (Minuten)** – der Wert **0** bedeutet: automatische Synchronisation ist deaktiviert. Ein Wert größer 0 lässt Tessera in diesem Abstand automatisch synchronisieren.
+- **„Jetzt synchronisieren“** – löst unabhängig vom Intervall sofort einen Sync-Lauf aus.
+
+**Wichtiges, im Code verifiziertes Verhalten:** Der Schalter „Aktiviert/Deaktiviert“ in diesem Abschnitt (Feld `isActive` der LDAP-Konfiguration) ist **kein** „Auto-Sync aus“-Schalter. Er entscheidet serverseitig, ob sich Benutzer, deren Konto kein lokales Passwort hat (also alle per LDAP importierten Konten), überhaupt noch **anmelden** dürfen. Wird dieser Schalter deaktiviert, werden nicht etwa nur zukünftige Sync-Läufe pausiert – jeder verzeichnisgeführte Benutzer wird sofort von der Anmeldung ausgesperrt, unabhängig vom Sync-Intervall. Um ausschließlich die automatische Synchronisation abzuschalten, ohne bestehende Anmeldungen zu blockieren, ist stattdessen das Sync-Intervall auf 0 zu setzen.
+
+Nach einem Lauf zeigt Tessera einen Ergebnisbericht mit mehreren Zeilen:
+
+1. **Erstellt / aktualisiert / deaktiviert** – wie viele Benutzerkonten neu angelegt, aktualisiert bzw. deaktiviert wurden. Deaktiviert werden Konten, deren zugehöriger AD-Eintrag im aktuellen Lauf nicht mehr gefunden wurde (der Benutzer bleibt dabei in der Datenbank erhalten, wird aber inaktiv gesetzt, siehe Kapitel 2).
+2. **Gruppenmitgliedschaften** – wie viele Mitgliedschaften über AD-gebundene Gruppen hinzugefügt bzw. entfernt wurden.
+3. **AD-Gruppen** – wie viele Gruppen neu übernommen (adoptiert), umbenannt oder gelöscht wurden.
+
+Darüber hinaus können folgende Zusatzabschnitte erscheinen:
+
+- **Standardgruppen-Markierung musste neu vergeben werden (n×)** – erscheint in Gelb/Amber, wenn im selben Lauf eine AD-gebundene Gruppe gelöscht wurde, die zugleich als Standardgruppe markiert war. Die Markierung wird dabei automatisch an eine andere Gruppe im Mandanten übergeben, damit nie ein Mandant ganz ohne Standardgruppe dasteht.
+- **Konten ohne E-Mail-Adresse** – listet Konten auf, die in diesem Lauf ohne E-Mail-Adresse angelegt oder aktualisiert wurden, weil die im AD hinterlegte Adresse bereits zu einem anderen Konto gehört. Anmeldung und Zugriff funktionieren für diese Konten normal, nur Benachrichtigungen per E-Mail erreichen sie nicht (siehe Kapitel 2).
+- **Ohne Anmeldenamen übersprungen** – Verzeichniseinträge ohne Anmeldename (`sAMAccountName`). Das ist ein normaler, kein fehlerhafter Zustand – typischerweise Kontakte oder Verteilerlisten im Verzeichnis, aus denen bewusst kein Tessera-Konto entsteht.
+- **Fehler / unerwartete Fehler** – Einträge, bei denen ein technischer Fehler auftrat. Die genaue technische Meldung steht ausschließlich im Server-Protokoll, im Bericht erscheint nur der betroffene Eintrag.
+
+Schlägt der Sync-Lauf als Ganzes fehl (z. B. weil die Verbindung nicht zustande kommt), erscheint statt eines Berichts mit lauter Nullen eine eindeutige Fehlermeldung, dass die Synchronisation nicht ausgeführt werden konnte.
+
+## 5. Modulverwaltung und Freigaben-Matrix
+
+Der Zugriff auf ein Modul läuft zweistufig:
+
+1. **Aktivierung für den Mandanten** (Administrator → Module): Ein Modul muss zunächst für den Mandanten aktiviert werden. Ohne Aktivierung ist es für niemanden im Mandanten nutzbar, unabhängig von jeder Freigabe.
+2. **Freigabe pro Gruppe oder Benutzer** (Freigaben-Matrix bzw. Benutzer-Detaildialog): Erst danach lässt sich steuern, welche Gruppen oder einzelnen Benutzer mit der Rolle USER Zugriff erhalten.
+
+ADMIN und SUPER_ADMIN benötigen dafür keine Freigabe – sie haben, sobald ein Modul mandantenweit aktiviert ist, automatisch Zugriff darauf. Die Freigaben-Matrix betrifft ausschließlich die Rolle USER.
+
+### Modul aktivieren
+
+Beim Umschalten eines deaktivierten Moduls auf „Aktiviert“ öffnet sich ein Bestätigungsdialog mit zwei Optionen:
+
+- **„Sofort freigeben“** – aktiviert das Modul für den Mandanten und gibt es zugleich für die als Standardgruppe markierte Gruppe frei (siehe Kapitel 3). Diese Option ist deaktiviert, solange keine Gruppe als Standardgruppe markiert ist; ein Hinweistext erklärt das im Dialog.
+- **„Später konfigurieren“** – aktiviert das Modul nur für den Mandanten, ohne irgendeine Freigabe zu setzen. Benutzer mit der Rolle USER sehen das Modul dann erst, nachdem eine Freigabe manuell über die Freigaben-Matrix erteilt wurde.
+
+Ein bereits aktiviertes Modul lässt sich direkt über den Schalter wieder deaktivieren, ohne Rückfrage.
+
+### Freigaben-Matrix
+
+Unter „Module → Freigaben-Matrix“ erscheint eine Tabelle: Zeilen sind die aktivierten Module (nach Kategorie gruppiert), Spalten sind die Gruppen des Mandanten (angezeigt mit ihrem internen Namen, falls gesetzt, sonst mit dem regulären Namen). Jede Zelle ist eine Checkbox, die die Freigabe für genau diese Kombination aus Modul und Gruppe an- oder abschaltet – Änderungen werden sofort gespeichert. Über das Suchfeld lässt sich sowohl nach Modul- als auch nach Gruppennamen filtern; ein Treffer auf nur einer Achse leert die andere Achse nicht.
+
+Ein Hinweistext unterhalb der Matrix erinnert daran, dass ADMIN und SUPER_ADMIN immer Zugriff auf alle aktiven Module haben und diese Matrix nur die Rolle USER betrifft.
+
+## 6. SMTP
+
+Unter **Administrator → SMTP** wird der Mailversand konfiguriert: Host, Port, Verschlüsselung (Keine, STARTTLS oder SSL-TLS), Benutzername, Passwort und die Absenderadresse. Das Passwortfeld wird aus Sicherheitsgründen nie mit dem gespeicherten Wert vorbefüllt – es bleibt beim Laden immer leer und wird nur mitgesendet, wenn tatsächlich ein neuer Wert eingegeben wurde.
+
+Über „Test-E-Mail an“ lässt sich optional eine echte Testnachricht an eine beliebige Adresse verschicken, um die Konfiguration vor dem produktiven Einsatz zu prüfen.
+
+Ohne funktionierende SMTP-Konfiguration versendet Tessera keine E-Mails. Das betrifft insbesondere:
+
+- den Versand von Passwort-Reset-Mails an Benutzer, die ihr Passwort vergessen haben;
+- E-Mail-Benachrichtigungen einzelner Module, die auf Mailversand angewiesen sind.
+
+Die Anmeldung selbst, der laufende Betrieb und die LDAP-Synchronisation sind von der SMTP-Konfiguration unabhängig und funktionieren auch ohne sie.
+
+## 7. Mandanten
+
+Der Bereich **Administrator → Mandanten** ist ausschließlich für SUPER_ADMIN sichtbar und zugänglich (siehe Kapitel 1). Er bietet:
+
+- eine Übersicht aller Mandanten mit Name, Slug, Status (Aktiv/Inaktiv) und Anzahl der zugehörigen Benutzer;
+- „Mandant erstellen“ mit den Feldern Name und Slug (Slug nur bei der Neuanlage editierbar, danach fest);
+- „Bearbeiten“, worüber sich ausschließlich der Name ändern lässt;
+- einen Schalter, um einen Mandanten zwischen Aktiv und Inaktiv umzuschalten;
+- „Löschen“ mit Bestätigungsdialog.
+
+Ein Mandant lässt sich **nicht löschen, solange er noch aktive Benutzer hat** – ein Löschversuch scheitert in diesem Fall mit einem entsprechenden Hinweis. Die Benutzer müssen zuvor deaktiviert oder einem anderen Mandanten zugeordnet werden.
+
+## 8. Fehlersuche für Administratoren
+
+| Symptom | Wahrscheinliche Ursache |
+|---|---|
+| Alle Benutzer aus dem Active Directory können sich plötzlich nicht mehr anmelden, obwohl der Sync-Lauf zuvor erfolgreich war. | Der Schalter „Aktiviert/Deaktiviert“ im Sync-Bereich der LDAP-Konfiguration wurde ausgeschaltet. Dieser Schalter sperrt sofort jede Anmeldung verzeichnisgeführter Konten – er ist **nicht** gleichbedeutend mit einer pausierten Synchronisation (siehe Kapitel 4). Zum Aussetzen nur der automatischen Synchronisation stattdessen das Sync-Intervall auf 0 setzen und den Schalter aktiviert lassen. |
+| „Verbindung testen“ oder ein Sync-Lauf schlägt mit einem Bind-/Authentifizierungsfehler fehl (z. B. einer Meldung, die auf einen fehlgeschlagenen Sicherheitskontext hinweist). | Häufigste Ursache ist eine vertauschte Eingabe von Bind-DN und Basis-DN, oder ein falsches Bind-Passwort. Beide Felder in den Verbindungseinstellungen prüfen. |
+| Ein AD-Benutzer wird zwar synchronisiert, aber ohne E-Mail-Adresse angelegt oder aktualisiert; Passwort-Reset-Mails erreichen ihn nicht. | Normales, dokumentiertes Verhalten seit E-Mail optional ist: Die im AD hinterlegte Adresse gehört bereits zu einem anderen Konto und wird deshalb nicht übernommen. Der Ergebnisbericht des Sync-Laufs listet solche Fälle unter „Konten ohne E-Mail-Adresse“ auf. Die Kollision im betroffenen Konto (dem Halter der Adresse) prüfen und die Adresse dort ggf. korrigieren. |
+| Eine AD-Gruppe erscheint im Sync-Bericht als gelöscht, obwohl sie im Verzeichnis noch existiert. | Die Gruppe wurde vermutlich außerhalb der konfigurierten Basis-DN(s) verschoben. Tessera prüft vor einer Löschung zwar zusätzlich die Domänenwurzel, kann eine Verschiebung aber nur innerhalb der erreichbaren Suchbereiche erkennen. Basis-DN(s) und Import-Filter prüfen. |
+| Ein Benutzer mit Rolle USER sieht ein Modul nicht, obwohl es für den Mandanten aktiviert ist. | Für dieses Modul fehlt eine Freigabe – weder direkt (Benutzer-Details) noch über eine Gruppe (Freigaben-Matrix). Prüfen, ob der Benutzer Mitglied der vorgesehenen Gruppe ist und ob die Matrix-Zelle für Modul/Gruppe gesetzt ist. |
+| Ein neu importierter/erstellter Benutzer hat unerwartet Zugriff auf ein Modul, das eigentlich niemandem freigegeben sein sollte. | Der Benutzer wurde automatisch Mitglied der Standardgruppe (siehe Kapitel 3), und dieser Gruppe wurde beim Aktivieren eines Moduls über „Sofort freigeben“ Zugriff erteilt. Freigaben-Matrix prüfen und ggf. die Standardgruppen-Freigabe für das betreffende Modul entfernen. |
+| Der Name einer AD-gebundenen Gruppe „springt“ nach jedem Sync-Lauf auf den AD-Namen zurück, obwohl ein anderer Name gewünscht ist. | Erwartetes Verhalten: Der Anzeigename einer AD-gebundenen Gruppe wird bei jedem Sync mit dem AD-Wert überschrieben. Für einen dauerhaft abweichenden Anzeigenamen den „Internen Namen“ im Bearbeiten-Dialog der Gruppe setzen – dieses Feld wird von der Synchronisation nie berührt. |
+| Ein AD-Gruppen-Import schlägt für eine bestimmte Gruppe mit einem Namenskonflikt fehl. | Es existiert bereits eine lokale (manuelle) Gruppe mit demselben Namen. Diese lokale Gruppe umbenennen oder – falls es sich tatsächlich um dieselbe Gruppe handeln soll – vor dem Import einen internen Namen dafür vergeben, dann erneut importieren. |
+| Eine Test- oder Benachrichtigungs-E-Mail kommt nicht an. | SMTP-Konfiguration unter Administrator → SMTP prüfen (Host, Port, Verschlüsselungsart, Zugangsdaten, Absenderadresse) und über „Verbindung testen“ mit einer Test-Empfängeradresse erneut prüfen. |
+| Ein Mandant lässt sich nicht löschen. | Der Mandant hat noch mindestens einen aktiven Benutzer. Alle Benutzer des Mandanten zunächst deaktivieren oder umziehen, dann erneut löschen. |