Authentifizierung & Sicherheit inkl. SSO

Als Werkseinstellung meldet sich jeder mit Benutzername und Passwort an. Statt des Benutzernamens geht auch die E-Mail-Adresse. Ist der Mailversand eingerichtet, steht unter dem Formular der Link „Do you need a password reset?" Der Mailversand gehört zu Professional.

Nach dem Anmelden bekommt der Browser einen Ausweis, der eine bestimmte Zeit gilt. Wie lange, legt die Karte „JWT token timer" fest. Erlaubt sind 1 bis 24 Stunden, empfohlen sind 12. Danach muss sich der Mensch neu anmelden.

Die Karte „Password policy" gilt für jedes Passwort, das im System gesetzt wird. Sie greift beim Anlegen eines Kontos, beim Ändern durch den Menschen selbst und beim Zurücksetzen durch den Administrator.

Eingestellt werden die Mindestlänge, welche Zeichenarten vorkommen müssen, nach wie vielen Tagen ein Passwort abläuft und wie viele alte Passwörter gesperrt bleiben. Bei den Tagen und der Sperrliste bedeutet die 0 „aus".

Die Regeln zu Groß- und Kleinbuchstaben sperren keine Sprache aus. Viele Schriften kennen diesen Unterschied gar nicht, und ein Zeichen aus einer solchen Schrift erfüllt beide Regeln von selbst.

Konten, die sich nur über SSO oder ein Verzeichnis anmelden, haben kein eigenes Passwort. Für sie gilt der Ablauf nicht. Ihre Regeln stehen beim Anbieter. Wurde ein vorhandenes Konto mit SSO verknüpft und hat es noch sein eigenes Passwort, gelten für dieses Passwort weiter der Ablauf und die Passwortregeln.

Die Karte „2FA Settings" legt fest, wer die Zwei-Faktor-Anmeldung nutzen muss. Unter „Two-factor requirement" wählst du eine von vier Stufen: „Off", „Administrators only", „Administrators and agents" oder „Everyone". „Everyone" schließt die Kunden ein. Eine neue Installation beginnt mit „Administrators only". Eine Installation, die es schon vorher gab, behält nach einem Update ihre bisherige Einstellung.

Wer sich das nächste Mal anmeldet und noch keinen zweiten Faktor hat, richtet ihn ein. Das System zeigt einen QR-Code für eine Authenticator-App und denselben Schlüssel zum Abtippen. Nach dem ersten Code ist der Faktor aktiv. Mit „Set up later" lässt sich die Einrichtung aufschieben, und die Anmeldung geht ohne sie weiter. Das geht höchstens 7 Tage lang, gezählt ab dem ersten Aufschieben. Die Zeile unter der Schaltfläche nennt die restlichen Tage. Danach ist die Einrichtung Pflicht.

Direkt danach erscheinen zehn Wiederherstellungscodes. Jeder davon ersetzt einmal den Code aus der App. Sie werden genau einmal angezeigt. Mit „Copy" oder „Download" sicherst du sie. „Download" geht immer. „Copy" geht meistens auch.

Verliert jemand sein Gerät und seine Codes, hilft der Administrator. In der Benutzerliste setzt die Schaltfläche mit dem durchgestrichenen Schild die Zwei-Faktor-Anmeldung dieses Menschen zurück. Beim nächsten Anmelden richtet er sie neu ein.

Die Codes hängen an der Uhr des Servers. Geht sie falsch, wird kein Code angenommen. Die Schaltfläche „Check now" auf derselben Karte vergleicht die Serverzeit mit einer öffentlichen Zeitquelle.

Meldet sich jemand über einen fremden Anmeldedienst an, fragt das System keinen Code ab. Der Anbieter hat den zweiten Faktor dann schon geprüft. Bei der Anmeldung über ein Verzeichnis ist das anders, dort gilt die Regel oben weiter.

Jeder Benutzer kann die Zwei-Faktor-Anmeldung für sein eigenes Konto einschalten. Das gilt für jede Rolle, auch wenn die Karte „2FA Settings" sie nicht verlangt. Öffne das Benutzermenü unten links in der Seitenleiste und wähle „Profile picture". Auf dieser Seite steht auch der Bereich „Two-factor authentication".

Der Bereich zeigt, ob die Zwei-Faktor-Anmeldung an ist. Solange sie aus ist, steht dort die Schaltfläche „Turn on". Sie fragt zuerst nach deinem Passwort. Danach erscheint ein QR-Code für die Authenticator-App und derselbe Schlüssel zum Abtippen. Nach dem ersten Code aus der App ist der Faktor aktiv.

Direkt danach erscheinen zehn Wiederherstellungscodes. Sichere sie mit „Copy" oder „Download". „I have saved my codes" schließt die Liste. Sie wird nur dieses eine Mal angezeigt.

Solange die Zwei-Faktor-Anmeldung an ist, zeigt der Bereich, wie viele Wiederherstellungscodes übrig sind. „New recovery codes" erzeugt zehn neue. Die alten Codes gelten dann nicht mehr. „Turn off" schaltet die Zwei-Faktor-Anmeldung wieder aus. Beide Schaltflächen verlangen den aktuellen Code aus der App. Ein Wiederherstellungscode wird dort nicht angenommen.

Verlangt die Karte „2FA Settings" die Zwei-Faktor-Anmeldung für deine Rolle, fehlt „Turn off". Eine Zeile im Bereich sagt das.

Ein falsches Passwort oder ein falscher Code zählt wie eine fehlgeschlagene Anmeldung. Der Schutz gegen das Raten von Passwörtern gilt also auch hier. Das Ein- und Ausschalten steht im Sicherheitsprotokoll. Schaltet ein Administrator seine eigene Zwei-Faktor-Anmeldung aus, meldet das Protokoll einen Alarm.

Konten, die sich nur über einen fremden Anmeldedienst anmelden, sehen statt der Schaltflächen einen Satz. Bei ihnen regelt der Anbieter den zweiten Faktor. Konten aus einem Verzeichnis geben im ersten Schritt ihr Passwort aus dem Verzeichnis ein.

Der Schutz läuft ohne Einstellung mit. Es gibt nichts einzuschalten. Der Hinweis dazu steht in der Karte „2FA Settings".

Er wirkt in zwei Stufen. Nach fünf Fehlversuchen für dasselbe Konto pausiert genau die Absenderadresse, von der sie kamen. Die Pause endet spätestens 15 Minuten nach dem ersten dieser Versuche. Von jeder anderen Adresse bleibt das Konto sofort nutzbar.

Das ist der wichtige Teil. Wer einen Anmeldenamen kennt, könnte sonst jeden Kollegen mit fünf falschen Passwörtern aussperren. Ein Passwort bräuchte er dafür nie.

Die zweite Stufe ist das Konto selbst. Es wird nach 20 Fehlversuchen für 15 Minuten gesperrt. Weil eine einzelne Adresse höchstens fünf davon beisteuern kann, braucht es dafür mehrere Adressen.

Eine erfolgreiche Anmeldung setzt beide Zähler zurück. Nach einem Neustart des Servers ist die Adressensperre weg, die Kontosperre bleibt. Für die Anmeldung über ein Verzeichnis gelten dieselben Zähler. Ist das Verzeichnis nicht erreichbar, zählt das nicht als Fehlversuch. Gibt es zu dem Namen noch kein Konto im Ticket-System, greift nur die Pause der Adresse.

In der Benutzerliste trägt ein so gesperrtes Konto die Marke „temporarily locked". Es bleibt in der Liste stehen. Nach 15 Minuten verschwindet die Marke von selbst.

Warten musst du nicht. In derselben Zeile steht eine Schaltfläche mit einem offenen Schloss. Sie hebt die Sperre sofort auf und räumt beide Zähler weg.

Das ist etwas anderes als „Archive". Diese Schaltfläche legt ein Konto dauerhaft still, und nur sie verbraucht oder gibt einen Bearbeiter-Platz frei.

Das Sicherheitsprotokoll hält zwei Arten von Ereignissen fest. Im Bereich „Sign-in" stehen fehlgeschlagene Anmeldungen, gesperrte Konten, Anmeldeversuche während einer Sperre, abgelehnte Zwei-Faktor-Codes und Passwortänderungen. Das gilt für die Anmeldung mit Passwort, über ein Verzeichnis und über SSO.

Im Bereich „Administration" steht, wer was geändert hat. Das sind Konten, Rollen, Berechtigungen, Sicherheitseinstellungen und Archive. Auch jeder Export des Protokolls steht dort.

Erfolgreiche Anmeldungen hält das System nur in zwei Fällen fest. Der erste Fall ist ein Administrator. Der zweite Fall ist eine Anmeldung nach Fehlversuchen für dasselbe Konto. Die gewöhnliche Anmeldung eines Bearbeiters oder Kunden steht nicht im Protokoll. Das Protokoll ist keine Anwesenheitsliste.

Meldet sich jemand mit einem Namen an, den es nicht gibt, steht im Eintrag „unknown account". Den eingetippten Namen speichert das System nicht. Manchmal ist er ein Passwort, das im falschen Feld gelandet ist.

Anmeldeereignisse speichern die IP-Adresse und den Browser. Verwaltungsaktionen speichern, wer sie ausgeführt hat, aber keine IP-Adresse. Passwörter, Codes und Inhalte von Tickets oder E-Mails stehen nie im Protokoll.

Die Seite zeigt die neuesten Einträge zuerst, 50 je Seite. Die Karte „Filters" grenzt die Liste ein. „Area" wählt Anmeldungen oder Verwaltung, „Event" eine einzelne Art von Ereignis. „Person" sucht im Namen dessen, der gehandelt hat, und dessen, der betroffen ist. „From" und „To" begrenzen die Tage. „Failures only" blendet alles aus, was gelungen ist.

Die Filter wirken erst nach einem Klick auf „Apply". „Reset" nimmt sie wieder weg.

„Export CSV" und „Export PDF" laden genau das herunter, was die Filter zeigen. Jede Datei enthält höchstens 10.000 Einträge. Passen mehr Einträge zu den Filtern, steht das in einem Hinweis bei den Schaltflächen zum Export. Das PDF ist in deiner Sprache und nennt oben Filter und Zeitraum. Datum und Uhrzeit stehen im Format, das unter „Settings → General Settings" eingestellt ist.

Die CSV-Datei bleibt immer englisch, und die Zeiten stehen in UTC. So kann ein Programm sie unabhängig von der Sprache lesen. Jeder Export steht selbst im Protokoll, als „Security log exported".

Sechs Ereignisse lösen einen Alarm aus. Das sind ein Konto, das nach Fehlversuchen gesperrt wurde, eine Rolle, die auf „Admin" geändert wurde, ein Konto, das gleich mit der Rolle „Admin" angelegt wurde, und eine zurückgesetzte Zwei-Faktor-Anmeldung eines Administrators. Dazu kommen archivierte Tickets, die aus den laufenden Daten entfernt wurden, und die Anmeldung eines Administrators nach Fehlversuchen.

Nach einem Alarm sieht jeder mit der Berechtigung oben auf jeder Seite ein gelbes Banner. Es nennt die Zahl der Alarme seit seinem letzten Besuch im Protokoll. Der Link „Open security log" führt hin. Mit dem Öffnen des Protokolls verschwindet das Banner. Vor dem ersten Besuch zählt es die Alarme der letzten sieben Tage.

Zusätzlich bekommt jedes aktive Konto mit der Berechtigung und einer E-Mail-Adresse eine Alarm-Mail. Das System sammelt die Alarme alle 15 Minuten und schickt je Person eine Mail, nicht eine je Ereignis. Die Mail nennt das Ereignis, die betroffene Person und die Zeit. Eine IP-Adresse steht nicht darin. Die Alarm-Mail gehört zu Professional.

Alte Einträge löscht der nächtliche Lauf. Die Fristen stehen unter „Settings → Security" in der Karte „Data protection" im Block „Security log retention". Anmeldeereignisse bleiben als Werkseinstellung 90 Tage, erlaubt sind 7 bis 365 Tage. Verwaltungsaktionen bleiben als Werkseinstellung 12 Monate, erlaubt sind 1 bis 120 Monate.

Jede Frist hat ihren eigenen Schalter: „Delete old sign-in events" und „Delete old administrator actions". Ist ein Schalter aus, bleiben diese Einträge stehen. Die Karte „Aufbewahrungsfristen" erklärt den nächtlichen Lauf.

Bei einer Datenauskunft bekommt die Person jeden Eintrag, in dem sie gehandelt hat oder betroffen ist. IP-Adresse und Browser stehen nur bei Einträgen dabei, die sie selbst ausgelöst hat, zum Beispiel ihre eigene Anmeldung. Wird die Person anonymisiert, löscht das System ihre Anmeldeereignisse. Ihre Verwaltungsaktionen bleiben stehen. Ihr Name wird dort durch den Platzhalter ersetzt.

Ein Hinweis an dich als Betreiber: Erfolgreiche Anmeldungen stehen nur bei Administratoren und nach Fehlversuchen im Protokoll. Das Protokoll zeigt trotzdem, wer wann was getan hat. In einer Firma mit Betriebsrat ist es deshalb ein Thema der Mitbestimmung.

Ganz oben steht der Hauptschalter „Enable single sign-on". Solange er aus ist, bleibt es bei Benutzername und Passwort. Alles, was du darunter einrichtest, wird gespeichert und wirkt erst, wenn du ihn einschaltest.

Die Karte „Active Directory / LDAP" bindet ein Verzeichnis in der eigenen Firma an. Du trägst den Server ein, den Suchbereich, den Filter, mit dem ein Mensch gefunden wird, und die Felder für E-Mail und Namen.

Das Konto zum Suchen ist freiwillig. Ohne eines fragt das System anonym an. Das Passwort des Menschen wird nur zum Anmelden am Verzeichnis benutzt und nirgends gespeichert.

Ein Verzeichnis bringt keinen zweiten Faktor mit. Verlangt die Sicherheitsseite eine Zwei-Faktor-Anmeldung, wird sie auch von diesen Menschen verlangt.

Die Karte „Identity providers" führt die fremden Anmeldedienste. Jeder bekommt eine eigene Kachel und eine eigene Schaltfläche auf der Anmeldeseite. „Add provider" legt einen neuen an.

Unter „Provider type" wählst du die Art. „Generic OIDC Provider" passt für Dienste wie Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 oder Ping Identity. „SAML 2.0 Provider" passt für dieselben Häuser, wenn sie über SAML angebunden werden sollen.

Daneben stehen sechs regionale Dienste zur Auswahl: LINE, Kakao, Naver, WeChat, WeCom und DingTalk. Ihre Adressen sind vorbelegt und stehen als grauer Text im Feld.

Der Name unter „Display name" steht später auf der Schaltfläche. Der Schalter daneben gilt nur für diesen einen Anbieter.

Bei der Rückruf-Adresse geh in dieser Reihenfolge vor. Trag zuerst nur einen Namen ein und klick auf „Save provider". Erst dann kennt das System die Nummer des Anbieters und zeigt die fertige Adresse unter „Redirect URI" an. Sie entsteht aus der öffentlichen Adresse dieser Installation, die unter „Settings → Security" hinterlegt ist. Genau diese Adresse benutzt das System bei der Anmeldung.

Diese Adresse kopierst du und trägst sie beim Anbieter ein. Sie muss dort auf das Zeichen genau stehen. Der Anbieter gibt dir dafür eine Kennung und ein Geheimnis, und die trägst du hier über „Edit" nach.

Das Feld „Allowed e-mail domains" schränkt ein, wer über diesen Anbieter hereinkommt. Bleibt es leer, ist jede Domain erlaubt.

Fehlt einem Anbieter noch etwas, trägt seine Kachel die rote Marke „Incomplete". Er erscheint dann nicht auf der Anmeldeseite. Der Text daneben sagt, welche Felder sein Typ braucht.

Vollständig eingerichtete Anbieter erscheinen trotzdem nicht, solange der Hauptschalter aus ist. Die Kachel sagt das in einer gelben Zeile.

Fällt deine Lizenz auf Basic zurück, bleibt die Anmeldung über SSO und das Verzeichnis in Betrieb. Auf dieser Seite kannst du Anbieter und Verzeichnis dann nur noch abschalten. Das Protokoll der Anmeldeversuche bleibt lesbar.

Der Schalter „Automatically create accounts on first sign-in" steht in derselben Karte wie der Hauptschalter. Er ist als Werkseinstellung an.

Meldet sich jemand zum ersten Mal über einen Anbieter an, sucht das System erst ein Konto, das schon zu diesem Anbieter gehört. Findet es keines, entsteht ein neues.

Das neue Konto bekommt die Rolle „Customer" und kein Team. Ein Kunde braucht keine Mitgliedschaft, um ein Ticket anzulegen, und ist damit sofort arbeitsfähig.

Kunden sind in beiden Editionen unbegrenzt. Ein so entstandenes Konto verbraucht also keinen Bearbeiter-Platz. Wer stattdessen Bearbeiter werden soll, bekommt die Rolle hinterher in der Benutzerverwaltung.

Gibt es schon ein Konto mit derselben E-Mail-Adresse, werden beide verknüpft. Das geschieht nur, wenn der Anbieter die Adresse als bestätigt meldet. Meldet er sie nicht als bestätigt, wird die Anmeldung abgelehnt.

Schaltest du den Schalter aus, kommt nur noch herein, wer schon ein Konto hat. Alle anderen werden abgewiesen.

Die Karte „Recent sign-in attempts" ganz unten zeigt die letzten 100 Anmeldeereignisse über SSO und das Verzeichnis. Sie stammen aus dem Sicherheitsprotokoll. Fehlversuche stehen immer darin. Eine erfolgreiche Anmeldung steht nur bei Administratoren darin und nach Fehlversuchen für dasselbe Konto. Es steht also nicht jede Anmeldung in der Liste.

Jede Zeile nennt Zeitpunkt, Anbieter, Ergebnis und Absenderadresse. Bei einem Fehlversuch steht der Grund daneben. Die Spalte „User" zeigt den Namen des Kontos. Gibt es kein Konto, zeigt sie die Adresse, die der Anbieter gemeldet hat, sonst „unknown account". Den eingegebenen Namen speichert das System nicht.

Die Anmeldung mit Benutzername und Passwort steht nicht in dieser Tabelle. Sie ist kein SSO. Du findest sie im Sicherheitsprotokoll.

Die Einträge werden als Werkseinstellung nach 90 Tagen gelöscht. Der Satz unter dem Kartentitel nennt die eingestellte Frist. Die Karte „Aufbewahrungsfristen" erklärt die Einstellung.

Nach der Installation nutzt dein Team das System in jedem Webbrowser. Der Installer fragt, wie das System erreichbar sein soll. Im Windows-Installer wählst du das auf der Seite „Erreichbarkeit". Unter Linux stellt install.sh dieselbe Frage und nummeriert die Varianten von 1 bis 5. Später änderst du es mit „Erreichbarkeit von SMITEY ändern". Deine Daten bleiben dabei, wo sie sind.

Die Variante „Nur im lokalen Netzwerk über die IP-Adresse (HTTP) - einfachste Variante" ist die Werkseinstellung. Dein Team öffnet das System unter http:// mit der IP-Adresse des Servers und dem Port, zum Beispiel http://192.168.1.20:8088. Der Port ist 8088, wenn du keinen anderen wählst. Port 80 geht auch. Dann braucht die Adresse keinen Port. Diese Variante braucht keinen Namen und kein Zertifikat.

Die Variante „Im lokalen Netzwerk über einen eigenen Namen (HTTP, HTTPS später möglich) - Sie haben internen DNS" arbeitet wie die erste, aber unter einem Namen wie ticket.firma.local. Den Namen legst du selbst in deinem internen DNS an. Er zeigt auf die IP-Adresse des Servers. Dann erreicht dein Team das System über den Namen und weiterhin über die IP-Adresse. Der Installer nennt danach die Adresse mit diesem Namen.

Bei beiden HTTP-Varianten gehen Passwörter und Tickets als Klartext durch dein Netzwerk. Administratoren sehen dann oben auf der Seite einen Hinweis.

Die anderen drei Varianten nutzen HTTPS: „Über eine öffentliche Domain mit HTTPS (automatisch via Let’s Encrypt)", „Im lokalen Netzwerk mit HTTPS und eigenem Zertifikat" und „Im lokalen Netzwerk mit HTTPS, Zertifikat von SMITEY erzeugt". Sie brauchen auf dem Server die Ports 80 und 443. Die nächste Karte beschreibt sie.

Für einen ersten Test reicht die erste Variante. Hat dein Netzwerk einen internen DNS, nimm die zweite. Soll das System aus dem Internet erreichbar sein, nimm die öffentliche Domain. Hat deine Firma eine eigene Zertifizierungsstelle, nimm im lokalen Netzwerk das eigene Zertifikat. Sonst lässt du SMITEY das Zertifikat erzeugen.

Ohne HTTPS gehen Passwörter und Tickets als Klartext durch dein Netzwerk. Eine neue Installation beginnt mit einfachem HTTP, damit sie sofort in jedem Webbrowser läuft. Solange ein Administrator das System über einfaches HTTP öffnet, erscheint oben auf der Seite ein Hinweis: „This connection is not encrypted." Öffnet er das System auf dem Server selbst unter „localhost", erscheint der Hinweis nicht. Bearbeiter und Kunden sehen ihn nie.

„How to switch on HTTPS" führt zu dieser Karte. „Hide for 30 days" blendet den Hinweis für dich aus. Die Einstellung gehört zu deinem Konto und gilt deshalb auch in einem anderen Browser. Nach 30 Tagen kommt der Hinweis wieder, solange die Verbindung noch nicht verschlüsselt ist.

Der SMITEY-Installer richtet HTTPS auf drei Wegen ein. Im Windows-Installer wählst du ihn auf der Seite „Erreichbarkeit", unter Linux stellt install.sh dieselbe Frage. Bei einem System, das schon läuft, öffnest du unter Windows „Erreichbarkeit von SMITEY ändern" auf dem Desktop oder im Startmenü. Unter Linux erledigt der Befehl unten dasselbe. Deine Daten bleiben dabei, wo sie sind.

Die Variante „Im lokalen Netzwerk mit HTTPS und eigenem Zertifikat" nutzt dein eigenes Zertifikat, zum Beispiel von deiner Firmen-CA. Der Installer fragt nach dem Namen des Systems und nach der Zertifikatsdatei mit ihrem Schlüssel. Eine PFX-Datei mit ihrem Passwort geht auch. Bevor er etwas ändert, prüft er das Zertifikat. Der Schlüssel muss passen, das Zertifikat muss gültig sein, und der Name muss im Zertifikat stehen.

Die Variante „Im lokalen Netzwerk mit HTTPS, Zertifikat von SMITEY erzeugt" braucht kein eigenes Zertifikat. SMITEY erzeugt eines selbst und erneuert es auch selbst. Das Stammzertifikat legt der Installer als SMITEY-root-ca.crt im Installationsordner ab. Installiere diese Datei auf jedem Rechner als vertrauenswürdiges Stammzertifikat, zum Beispiel per Gruppenrichtlinie. Bis dahin zeigen die Browser eine Warnung.

Die Variante „Über eine öffentliche Domain mit HTTPS (automatisch via Let’s Encrypt)" holt ihr Zertifikat von Let’s Encrypt. Sie braucht eine öffentliche Domain, die auf den Server zeigt. Der Server muss dafür aus dem Internet erreichbar sein.

Bei beiden Varianten im lokalen Netzwerk darf der Name ein Name wie ticket.firma.local sein, ein einzelnes Wort wie helpdesk oder eine IPv4-Adresse. Alle drei Wege brauchen auf dem Server die Ports 80 und 443. Nutzt ein anderes Programm sie, bricht der Installer ab und ändert nichts. Das System ist danach unter https:// und dem Namen erreichbar, ohne Port.

Dein eigenes Zertifikat läuft irgendwann ab. Ab 30 Tagen vorher sehen Administratoren oben auf der Seite einen Hinweis mit dem Datum. Ab 7 Tagen vorher ist er rot. In Professional bekommen alle Administratoren mit E-Mail-Adresse zusätzlich 30 und 7 Tage vorher eine Mail. Zum Erneuern öffnest du wieder „Erreichbarkeit von SMITEY ändern", wählst die Variante mit dem eigenen Zertifikat und gibst die neuen Dateien an.

Die Datei HTTPS-GUIDE.txt, die mit der Installation kommt, beschreibt jeden Schritt. Dazu gehören das Verteilen des Stammzertifikats und die Schritte von Hand.