1. Einleitung
In diesem Artikel zeigen wir Ihnen alles rund um die Benutzerverwaltung in Checkmk. Doch bevor wir in die Details gehen können, müssen wir erst einige Begriffe klären.
Ein Benutzer (user) ist in Checkmk jemand, der Zugang zur Benutzeroberfläche hat. Er hat eine oder mehrere Rollen. Aus den Rollen ergeben sich Berechtigungen (permissions).
Sobald ein Benutzer für bestimmte Hosts und Services zuständig ist, wird er als Kontakt bezeichnet. Ein Kontakt sieht normalerweise nur seine eigenen Hosts und Services in der Monitoring-Umgebung und wird eventuell über Probleme benachrichtigt.
Es gibt auch Benutzer, die keine Kontakte sind.
Ein Beispiel dafür ist cmkadmin, der beim Erzeugen einer Instanz automatisch angelegt wird.
Dieser darf zwar alle Hosts und Services sehen, aber nur, weil in seiner Rolle Administrator die Berechtigung See all hosts and services enthalten ist und nicht, weil er für alles ein Kontakt wäre.
Wenn ein Kontakt nur zum Zwecke der Benachrichtigung angelegt wurde (z.B. zur Weiterleitung von Benachrichtigungen an ein Ticketsystem), dann kann es sinnvoll sein, ihn so anzulegen, dass kein Login in die Oberfläche möglich ist.
Ein Kontakt ist immer Mitglied von einer oder mehreren Kontaktgruppen.
Der Zweck dieser Gruppen ist die Zuordnung von Kontakten zu Hosts und Services.
Zum Beispiel könnte der Kontakt hhirsch in der Kontaktgruppe linux sein und diese wiederum per Regel allen Linux-Hosts zugeordnet.
Eine direkte Zuordnung von Kontakten zu Hosts oder Services ist nicht möglich und würde in der Praxis auch Schwierigkeiten bereiten (z.B. beim Ausscheiden eines Benutzers).
Noch einmal zusammengefasst:
Benutzer können die Benutzeroberfläche verwenden.
Kontakte sind Benutzer, die für bestimmte Hosts und Services zuständig sind.
Kontaktgruppen legen fest, für was jemand zuständig ist.
Rollen legen fest, welche Berechtigungen jemand hat.
2. Benutzerverwaltung in der Konfigurationsumgebung
2.1. Übersicht
Die Benutzerverwaltung finden Sie unter Setup > Users > Users. In einer frisch angelegten Instanz sieht diese Seite so aus (im Bild nur um einige Tabellenspalten gekürzt):
Das obige Bild zeigt alle Benutzer, welche automatisch beim Erzeugen der Instanz angelegt wurden:
Ein Automationsbenutzer, gefolgt von dem einzigen Benutzer (cmkadmin) für die interaktive Anmeldung mit Passwort.
Bei der Checkmk-Appliance kann dieser Benutzer anders heißen, da Sie dessen Namen und Passwort selbst festlegen.
Dieser Benutzer cmkadmin hat folgende Eigenschaften:
Er hat die Rolle Administrator und damit alle Berechtigungen.
Er ist für nichts Kontakt und bekommt keine Benachrichtigungen.
Er darf trotzdem alles sehen (wegen seiner Rolle Administrator).
Das Passwort, das beim Erstellen der Instanz vergeben wurde, sollten Sie auf jeden Fall ändern!
Das Formular zum Anlegen eines neuen Benutzers (mit 
) oder Editieren eines bestehenden Benutzers (mit 
) ist in mehrere Abschnitte unterteilt.
Im ersten geht es um die Identität.
2.2. Identität
Wie immer in Checkmk ist die ID eines Datensatzes (hier Username) später nicht änderbar. Sie wird für die Anmeldung verwendet und auch als interner Schlüssel in sämtlichen Dateien und Datenstrukturen.
Die E-Mail-Adresse ist optional und nur dann notwendig, wenn der Benutzer ein Kontakt werden soll, der per E-Mail benachrichtigt werden soll (SMTP-Konfiguration notwendig). Analog ist das Feld Pager address für die Benachrichtigung per SMS oder ähnliche Systeme vorgesehen. Wenn Sie eigene Benachrichtigungsskripte schreiben, können Sie auf die Werte in den Feldern zugreifen und sie für beliebige Zwecke verwenden.
Über Monitored sites dürfen Sie optional beschränken, auf welche der vorhandenen Instanzen zugegriffen werden darf. Praktisch ist das vor allem bei sehr großen Umgebungen, etwa einem verteilten Monitoring mit Hunderten von Instanzen: Sofern ein Benutzer nur einen Teil dieser Instanzen für seine Hosts benötigt, wird die GUI auch nur die ausgewählten Instanzen kontaktieren, um Ansichten aufzubauen — was wiederum der Performance enorm zugutekommt.
2.3. Sicherheit
Dieser Kasten dient der Anmeldung und Berechtigung.
Die Option Automation secret for machine accounts ist für Konten gedacht, die skriptgesteuert per HTTP/HTTPS auf Checkmk zugreifen und sich über die URL authentifizieren. Wie das geht, zeigen wir Ihnen weiter unten.
Bei den Rollen müssen Sie mindestens eine auswählen. Theoretisch können Sie einem Benutzer auch mehrere Rollen geben. Er bekommt dann die Rechte von allen diesen Rollen. Mit den vordefinierten Rollen macht dies jedoch wenig Sinn.
Wenn Sie einen Benutzer mit der Option disable the login to this account sperren, wird er in der Tabelle mit dem Symbol 
dargestellt.
Er kann sich dann nicht mehr anmelden, bleibt aber trotzdem im System erhalten.
Falls er ein Kontakt ist, sind auch die Benachrichtigungen von der Sperre nicht beeinflusst und er wird weiterhin E-Mails etc. erhalten.
War der Benutzer zum Zeitpunkt der Sperrung gerade angemeldet, so wird er automatisch abgemeldet.
2.4. Kontaktgruppen
Sobald Sie einen Benutzer einer Kontaktgruppe oder mehreren zuordnen, wird dieser Benutzer zum Kontakt. Bei einer neuen Instanz wird automatisch die Kontaktgruppe Everything angelegt, die immer alle Hosts und alle Services enthält. Ein Benutzer in dieser Gruppe ist automatisch für alle Hosts und Services zuständig.
2.5. Benachrichtigungen
Im Kasten Notifications können Sie über die Option Receive fallback notifications festlegen, dass dieser Kontakt Benachrichtigungen bekommt, wenn keine Benachrichtigungsregel greift.
2.6. Persönliche Einstellungen
Alle Einstellungen in diesem Kasten kann der Benutzer über User > Edit profile auch selbst ändern (außer in der Rolle Guest user). Abgesehen von der Auswahl der Sprache der Oberfläche handelt es sich um selten benötigte Einstellungen. Details dazu finden Sie wie immer in der Inline-Hilfe.
2.7. Oberflächeneinstellungen
Auch die Oberflächeneinstellungen können Benutzer selbst über User > Edit profile anpassen. Besonders interessant ist die Option Show more / Show less zur Festlegung, ob Checkmk in der Oberfläche mehr oder weniger anzeigen soll. Wenn Sie immer alles sehen wollen, können Sie dies hier mit Enforce show more erzwingen.
3. Kontaktgruppen
3.1. Kontaktgruppen anlegen und editieren
Kontaktgruppen sind das Bindeglied zwischen Hosts und Services auf der einen und Kontakten auf der anderen Seite.
Jede Kontaktgruppe repräsentiert eine Zuständigkeit für einen bestimmten Bereich in Ihrer IT-Landschaft.
So könnte z.B. die Kontaktgruppe SAP alle Personen umfassen, die SAP-Systeme betreuen, und allen Hosts und Services zugeordnet sein, die Dienste in diesem Umfeld bereitstellen.
Die Kontaktgruppen verwalten Sie über Setup > Users > Contact groups. Folgende Abbildung zeigt dieses Modul mit drei manuell erstellten Kontaktgruppen:
Das Anlegen einer neuen Gruppe ist trivial. Wie immer ist die ID unveränderlich und der Alias ein Anzeigename, den Sie später jederzeit anpassen können:
Die neue Kontaktgruppe ist erst einmal leer in doppelter Hinsicht: Sie enthält weder Kontakte noch Hosts oder Services. Die Zuordnung von Kontaktgruppen zu Kontakten geschieht über die Benutzerprofile, wie Sie schon beim Editieren des Benutzers gesehen haben.
Inventar-Sichtbarkeit festlegen
Zusätzlich können Sie die Sichtbarkeit des mit der HW-/SW-Inventur gefundenen Inventars festlegen. Standardmäßig ist das komplette Inventar sichtbar, es lässt sich aber auch komplett unterdrücken oder gezielt freischalten mit der Option Allowed to see parts of the tree und den internen Inventur-Pfaden:
Um die geforderten Pfadinformationen eingeben zu können, müssen Sie diese zuerst aus den Inventurdaten auslesen. Mit diesen Informationen können Sie dann die Pfade und Schlüssel befüllen und so beispielsweise ausschließlich einige ausgewählte Inventurdaten zum Prozessor sichtbar machen (Modell und Architektur):
3.2. Hosts in eine Kontaktgruppe aufnehmen
Zum Aufnehmen von Hosts in Kontaktgruppen gibt es zwei Methoden: über Ordner und über Regeln. Sie können auch beide Methoden kombinieren. In diesem Fall bekommt der Host dann die Summe der jeweiligen Kontaktgruppen zugeordnet.
Zuweisung über Ordner
Zu den Eigenschaften eines Ordners gelangen Sie über Folder > Properties während Sie im Ordner sind. Dort finden Sie die Option Permissions. Aktivieren Sie diese Checkbox, um zur Auswahl der Kontaktgruppen zu kommen:
Der eigentliche Sinn dieser Option ist das Setzen von Berechtigungen für das Pflegen von Hosts, was wir weiter unten im Detail zeigen.
Sobald Sie Berechtigungen für bestimmte Kontaktgruppen vergeben, können Sie diese Gruppen im gleichen Zug wiederum als Kontaktgruppen für die Hosts im Monitoring eintragen lassen. Dabei können Sie entscheiden, ob die Zuordnungen auch für Hosts in Unterordnern gelten sollen und, ob die Services der Hosts ebenfalls explizit diese Gruppen bekommen sollen. Services ohne explizite Zuweisung erben nämlich alle Kontaktgruppen eines Hosts, auch solche, die durch Regeln zugewiesen wurden.
 |
Die Vererbung des Permissions-Attributs über die Ordner ist an dieser Stelle außer Kraft gesetzt. Dies erlaubt Ihnen, in Unterordnern weitere Kontaktgruppen hinzuzufügen. Die Zuordnung geschieht also kumulativ auch über alle Elternordner, falls in diesen die Option Add these groups as contacts to all hosts in all subfolders of this folder aktiviert ist. |
Übrigens finden Sie die Kontaktgruppenoptionen in vereinfachter Form auch direkt in den Details eines Hosts. Somit können Sie einzelnen Hosts auch hierüber Kontaktgruppen zuordnen. Da das aber schnell recht unübersichtlich werden kann, sollten Sie das nur in Ausnahmefällen tun und bei Bedarf eventuell lieber mit Regeln arbeiten.
Zuweisung über Regeln
Die zweite Methode — das Zuweisen von Kontaktgruppen über Regeln — ist etwas umständlicher, aber dafür deutlich flexibler. Und es ist sehr nützlich, wenn Sie Ihre Ordnerstruktur nicht nach organisatorischen Prinzipien aufgebaut haben und daher die Ordner nicht eindeutig Kontaktgruppen zuordnen können.
Den dafür nötigen Regelsatz Assignment of hosts to contact groups erreichen Sie über Setup > Hosts > Host monitoring rules. In diesem Regelsatz finden Sie eine vordefinierte Regel, die beim Erzeugen der Instanz angelegt wurde und welche alle Hosts der Kontaktgruppe Everything zuweist.
Beachten Sie, dass dieser Regelsatz so definiert ist, dass alle zutreffenden Regeln ausgewertet werden und nicht nur die erste! Es kann nämlich durchaus nützlich sein, dass ein Host zu mehreren Kontaktgruppen gehört. In diesem Fall benötigen Sie für jede Zuweisung eine eigene Regel.
3.3. Services in Kontaktgruppen aufnehmen
Es ist nicht immer sinnvoll, dass ein Service in den gleichen Kontaktgruppen ist wie sein Host. Daher können Sie über den Regelsatz Assignment of services to contact groups Services zu Kontaktgruppen zuordnen — unabhängig von den Kontaktgruppen des Hosts. Dabei gelten folgende Regeln:
Wenn einem Service keine Kontaktgruppe zugeordnet ist, erhält er automatisch die gleichen Kontaktgruppen wie sein Host.
Sobald einem Service mindestens eine Kontaktgruppe explizit zugeordnet ist, erbt er die Kontaktgruppen vom Host nicht mehr.
In einer einfachen Umgebung genügt es also, wenn Sie nur den Hosts Kontaktgruppen zuordnen. Sobald Sie mehr Differenzierung brauchen, können Sie auch Regeln für die Services anlegen.
3.4. Kontrolle der Zuordnung
Ob Sie alle Regeln und Ordner richtig konfiguriert haben, können Sie in den Details eines Hosts oder Services in der Monitoring-Umgebung überprüfen. Dort finden Sie die Einträge Host contact groups und Host contacts (bzw. Service contact groups und Service contacts), welche die letztendliche Zuordnung für dieses Objekt auflisten:
4. Sichtbarkeit von Hosts und Services
4.1. Übersicht
Die Tatsache, dass ein normaler Benutzer (Rolle Normal monitoring user) nur solche Objekte sieht, für die er ein Kontakt ist, ist umso wichtiger, je größer Ihre Monitoring-Umgebung ist. Das sorgt nicht nur für Übersicht, sondern verhindert auch, dass Benutzer dort eingreifen, wo sie nichts zu suchen haben.
Als Administrator (Rolle Administrator) dürfen Sie natürlich immer alles sehen. Gesteuert wird das über die Berechtigung See all host and services. In Ihren persönlichen Einstellungen finden Sie bei Visibility of hosts/services die Checkbox Only show hosts and services the user is a contact for. Mit dieser können Sie das „Alles Sehen“ freiwillig aufgeben und sich nur noch die Hosts und Services anzeigen lassen, für die Sie ein Kontakt sind. Diese Option ist für Doppelrollen gedacht — also für jemanden, der gleichzeitig Administrator und auch normaler Benutzer ist.
Die Rolle Guest user ist so voreingestellt, dass auch ihre Benutzer alles sehen können. Ein Eingreifen oder persönliche Einstellungen sind hier deaktiviert.
Für normale Benutzer ist die Sichtbarkeit in der Monitoring-Umgebung so umgesetzt, dass sich das System so anfühlt, als wären die Hosts und Services, für die man nicht Kontakt ist, überhaupt nicht vorhanden. Unter anderem berücksichtigen folgende Elemente die Sichtbarkeit:
Tabellenansichten von Hosts und Services
Das Snapin Overview der Seitenleiste
Berichte, die von dem Benutzer erstellt werden
4.2. Sichtbarkeit von Services
Wie wir oben gezeigt haben, ist es möglich, dass Sie für einen Host Kontakt sind, aber nicht für alle seine Services. Trotzdem werden Sie in so einem Fall alle Services des Hosts in der GUI sehen können.
Diese Ausnahme ist so voreingestellt, weil das meistens nützlich ist. Das bedeutet in der Praxis z.B., dass die Kollegin, die für den Host an sich verantwortlich ist, auch solche Services sehen kann, die mit dem eigentlichen Host (Hardware, Betriebssystem etc.) nichts zu tun haben. Trotzdem erhält sie für diese keine Benachrichtigungen!
Wenn Ihnen das nicht gefällt, können Sie das in den kommerziellen Editionen umstellen über Global settings > Monitoring core > Authorization settings. Wenn Sie dort Services auf Strict - Visible if user is contact for the service umstellen, können Benutzer Services nur noch dann sehen, wenn sie direkt als Kontakt dem Service zugeordnet sind.
Das Ganze hat übrigens nichts damit zu tun, dass ein Service die Kontaktgruppen seines Hosts erbt, falls für ihn keine eigenen definiert sind. Denn dann wären Sie ja Kontakt für den Service (und würden auch deren Benachrichtigungen bekommen).
4.3. Host- und Service-Gruppen
Die zweite Option in der globalen Einstellung Authorization settings betrifft Host- und Service-Gruppen. Normalerweise können Sie eine Gruppe immer dann sehen, wenn Sie mindestens ein Element der Gruppe sehen können. Allerdings sieht die Gruppe dann für Sie aus, als würde sie auch nur die für Sie sichtbaren Element enthalten.
Ein Umschalten auf Strict - Visible if all members are visible macht alle Gruppen unsichtbar, in denen Sie für mindestens einen Host bzw. Service kein Kontakt sind.
Beachten Sie, dass diese beiden Einstellungen zur Sichtbarkeit keinen Einfluss auf die Benachrichtigungen haben.
5. Benachrichtigungen
Kontaktzuordnungen haben auch einen Einfluss auf die Benachrichtigungen. Checkmk ist so voreingestellt, dass im Falle eines Problems alle Kontakte des betroffenen Hosts oder Services benachrichtigt werden. Das geschieht durch eine globale Benachrichtigungsregel, die bei neuen Instanzen automatisch angelegt wird. Dies ist ein sehr sinnvolles Verhalten.
Trotzdem können Sie bei Bedarf eine Regel anpassen oder durch weitere Regeln ergänzen, so dass Benachrichtigungen im Extremfall sogar ganz unabhängig von den Kontaktgruppen geschehen. Häufiger Grund dafür ist, dass ein Benutzer sich wünscht, bestimmte Benachrichtigungen nicht zu bekommen oder umgekehrt über Probleme bei einzelnen Hosts oder Services informiert zu werden, auch wenn er für diese nicht zuständig (und folglich kein Kontakt) ist.
Details zu der von Checkmk mitgelieferten globalen Benachrichtigungsregel erfahren Sie im Leitfaden für Einsteiger.
6. Rollen und Berechtigungen
6.1. Vordefinierte Rollen
Checkmk vergibt Berechtigungen an Benutzer immer über Rollen — niemals direkt. Eine Rolle ist nichts anderes als eine Liste von Berechtigungen. Wichtig ist, dass Sie verstehen, dass Rollen das Niveau von Berechtigungen definieren und nicht den Bezug zu irgendwelchen Hosts oder Services. Dafür sind die Kontaktgruppen da.
Checkmk wird mit folgenden vordefinierten Rollen ausgeliefert, welche niemals gelöscht, aber beliebig angepasst werden können:
| Name der Rolle | Alias | Berechtigungen | Einsatzzweck |
|---|---|---|---|
|
Administrator |
Alle Berechtigungen — insbesondere das Recht, Berechtigungen zu ändern. |
Der Checkmk-Administrator, der das Monitoring-System an sich betreut. |
|
Normal monitoring user |
Darf nur die eigenen Hosts und Services sehen, in der Weboberfläche nur in für sie freigegebenen Ordnern Änderungen machen und darf generell nichts machen, was andere Benutzer beeinflusst. |
Der normale Checkmk-Benutzer, der das Monitoring nutzt und auf Benachrichtigungen reagiert. |
|
Agent registration user |
Die Berechtigung, den Checkmk-Agenten eines Hosts beim Checkmk-Server für die TLS-verschlüsselte Datenübertragung zu registrieren — sonst nichts. |
Diese Rolle ist dem Automationsbenutzer |
|
Guest user |
Darf alles sehen aber nichts ändern. |
Gedacht zum einfachen „Gucken“, wobei sich alle Gäste ein gemeinsames Konto teilen. Auch nützlich für öffentliche Statusmonitore, die an der Wand hängen. |
|
no_permissions |
Darf gar nichts. |
Diese Rolle ist nicht für die direkte Zuweisung gedacht. Stattdessen kann sie verwendet werden, um neue Rollen nur mit der erforderlichen Mindestberechtigung zu erstellen. Sollten in zukünftigen Checkmk-Versionen neue Berechtigungen hinzukommen oder sich bestehende ändern, können Sie trotzdem sicher sein, dass eine von no_permissions abgeleitete Rolle keine neuen, unerwarteten Berechtigungen erhält. |
Die Rollen werden über Setup > Users > Roles & permissions verwaltet:
Übrigens: Beim Erzeugen einer neuen Checkmk-Instanz wird für die Anmeldung an der Checkmk-Oberfläche nur ein Benutzer (cmkadmin) der Rolle Administrator angelegt.
Die anderen Rollen werden erst mal nicht verwendet.
Wenn Sie einen Gastbenutzer wünschen, müssen Sie diesen selbst anlegen.
6.2. Bestehende Rollen anpassen
Wie üblich gelangen Sie über das Symbol in den Editiermodus für eine Rolle:
Welche Bedeutung die zahlreichen Berechtigungen haben (hier in Auszügen dargestellt), erfahren Sie aus der Inline-Hilfe.
Das Besondere hier: Für jede Berechtigung gibt es drei Auswahlmöglichkeiten: yes, no und default (yes) bzw. default(no). Am Anfang stehen alle Werte auf default. Für die Berechtigung selbst macht es erst mal keinen Unterschied, ob Sie yes oder default (yes) eingestellt haben. Allerdings kann eine neue Version von Checkmk den Standardwert ändern (auch wenn das sehr selten vorkommt). Eine von Ihnen explizite gemachte Einstellung wäre dann von der Änderung nicht betroffen.
Außerdem können Sie durch dieses Prinzip sehr schnell erkennen, wo Ihre Checkmk-Installation vom Standard abweicht.
6.3. Eigene Rollen definieren
Vielleicht sind Sie überrascht, dass es keinen Knopf gibt, um eine neue Rolle anzulegen.
Dahinter steckt Absicht.
Neue Rollen erschaffen Sie durch ein Ableiten von bestehenden Rollen mittels 
Clone.
Die neue Rolle wird nicht einfach als Kopie erzeugt, sondern behält den Bezug zur Ausgangsrolle (Based on role):
Diese Verbindung hat eine wichtige Funktion. Denn alle Berechtigungen der geklonten Rolle, die nicht explizit gesetzt sind (also noch auf default stehen), werden von der Ausgangsrolle geerbt. Änderungen in der Ausgangsrolle schlagen also durch. Das ist sehr praktisch, wenn man bedenkt, wie viele Berechtigungen es gibt. Bei einer simplen Kopie könnten Sie sonst leicht den Überblick verlieren, was eigentlich das Besondere an Ihrer selbst definierten Rolle ausmacht.
Das Ableiten löst noch ein weiteres Problem: Da wir Checkmk rege weiterentwickeln, kommen immer wieder neue Berechtigungen hinzu. Jedes mal entscheiden wir dann, in welcher der drei Rollen Administrator, Normal monitoring user und Guest user die neue Berechtigung enthalten sein soll. Da jede Ihrer eigenen Rollen von genau einer der vordefinierten Rollen abgeleitet ist, wird dann die neue Berechtigung automatisch auf einen sinnvollen Wert voreingestellt. Es wäre doch sehr unpraktisch, wenn Sie z.B. eine eigene Benutzerrolle definieren und dort neue Berechtigungen immer fehlen würden. Dann müssten Sie bei jedem neuen Feature Ihre Rolle anpassen, damit Ihre Benutzer diese nutzen könnten.
6.4. Rollen vergleichen mit der Matrixansicht
Wenn Sie die Berechtigungen in den einzelnen Rollen vergleichen möchten, hilft die Matrixansicht, zu erreichen über Setup > Users > Roles & permissions > Roles > Permission matrix.
Der Menüeintrag erzeugt folgende Ansicht, in der Sie nicht nur die Berechtigungen der einzelnen Rollen vergleichen können,
sondern auch die Stellen sehen, an denen explizit Berechtigungen gesetzt (Symbol 
) bzw. entfernt (Symbol 
) wurden.
7. Persönliche Einstellungen
Einen kleinen Teil der Benutzereinstellungen kann jeder Benutzer für sein Profil selbst verwalten. Eine genaue Beschreibung aller Optionen finden Sie im Artikel zur Benutzeroberfläche.
Dazu ein Hinweis für das verteilte Monitoring: In einer verteilten Umgebung werden nach jeder Änderung die neuen Einstellungen sofort auf alle Monitoring-Instanzen übertragen. Nur so ist sichergestellt, dass insbesondere ein neu vergebenes Passwort auch sofort überall funktioniert — und nicht erst beim nächsten Aktivieren der Änderungen. Das klappt allerdings nur für Instanzen, die zu diesem Zeitpunkt auch über das Netzwerk erreichbar sind. Alle andere Instanzen bekommen die Aktualisierungen beim nächsten erfolgreichen Aktivieren der Änderungen.
8. Besondere Benutzer
Bis zu diesem Punkt haben wir beschrieben, wie man einen „ganz normalen“ Benutzer anlegt. Nun gibt es aber aus verschiedenen Gründen auch einzelne Benutzer, die besondere Rechte oder Funktionen haben.
Dazu zählen zum Beispiel Administratoren und Automationsbenutzer. Auf deren Besonderheiten gehen wir im Folgenden ein.
8.1. Administrator
Bei der Installation von Checkmk wird - wie oben bereits erwähnt - standardmäßig ein Administrator angelegt.
Dieser heißt cmkadmin.
Mit diesem Administrator können Sie nun beliebig weiterarbeiten.
Möglicherweise wollen Sie aber genau diesen Standard-Administrator nicht nutzen.
Beispielsweise aufgrund firmeninterner Vorschriften, weil Sie mehrere Administratoren definieren wollen oder auch um Sicherheitsempfehlungen wie dem OWASP Application Security Verification Standard (ASVS) zu genügen.
Zunächst einmal ist ein Administrator ein Benutzer wie jeder andere auch. Er wird also erstellt, wie im Kapitel Benutzerverwaltung in der Konfigurationsumgebung beschrieben. Entscheidend sind jedoch die Rechte, die ihm über die ausgewählte Rolle zugewiesen werden.
Wählen Sie beim Anlegen des Benutzers die Rolle Administrator aus. Alle weiteren Einstellungen erfolgen auch für den Administrator entsprechend der persönlichen Präferenzen oder betriebsinternen Vorgaben.
8.2. Automationsbenutzer (für Webdienste)
Bei der Anbindung von Checkmk an andere Systeme kommt oft der Wunsch auf, bestimmte Tätigkeiten, die normalerweise über die GUI stattfinden, zu automatisieren. Einige Beispiele dafür sind:
Setzen und Entfernen von Wartungszeiten per Skript.
Verwalten von Hosts per REST-API.
Abrufen von Daten aus Tabellenansichten als CSV oder JSON zum Zwecke der Weiterverarbeitung.
Abrufen des aktuellen Status von BI-Aggregaten, um diese als Service anzulegen.
In diesen Situationen muss eine externe Software bestimmte URLs der Checkmk-Oberfläche automatisiert abrufen können. Und da stellt sich natürlich die Frage, wie hier die Benutzeranmeldung geschieht. Der normale Weg über den Anmeldedialog ist umständlich und erfordert den Abruf von mehreren URLs hintereinander und das Speichern eines Cookies.
Um dies zu vereinfachen, bietet Checkmk das Konzept der Automationsbenutzer. Diese Benutzer sind ausschließlich für eine Fernsteuerung vorgesehen und erlauben keine normale Anmeldung über die GUI. Die Authentifizierung geschieht hier über HTTP Basic Authentication.
In jeder Checkmk-Instanz ist ein Automationsbenutzer bereits eingerichtet, für die Registrierung des Agenten beim Checkmk-Server zur TLS-verschlüsselten Datenübertragung.
Für andere Aufgaben können Sie weitere Automationsbenutzer erstellen, in der Regel mit der Rolle Administrator.
Sie legen einen Automationsbenutzer wie einen normalen Benutzer an, vergeben aber kein normales Passwort, sondern ein Automationspasswort (Automation secret).
Dieses können Sie mit dem 
Würfel automatisch erstellen lassen:
 |
Die HTTP-Basisauthentifizierung benötigt das Automationspasswort standardmäßig im Klartext.
Setzen Sie dazu die Option Store the secret in cleartext.
Gespeichert wird das Passwort dann im Instanzverzeichnis unter |
Ein Automationsbenutzer hat genauso wie ein normaler Benutzer eine Rolle und kann auch Kontakt sein. Damit können Sie also die Berechtigungen und die Sichtbarkeit von Hosts und Services nach Bedarf einschränken.
Beim automatischen Abruf von Webseiten geben Sie dann den Header der HTTP-Basisauthentifizierung an, der grundsätzlich so aussieht: Authorization: Basic 1234567890abcdef.
Die Zeichenfolge ist dabei die Base64-kodierte Form von username:password.
Hier ist ein Beispiel für den Abruf einer Ansicht im JSON-Format mit dem Automationsbenutzer automation und dessen Automationspasswort — die Base64-Kodierung erledigt Curl:
root@linux# curl --user automation:a8075a39-e7fe-4b5c-9daa-02635 'http://moni01.mycompany.net/mysite/check_mk/view.py?view_name=svcproblems&output_format=json'
[
"service_state",
"host",
"service_description",
"service_icons",
"svc_plugin_output",
"svc_state_age",
"svc_check_age",
"perfometer"
],
[
"CRIT",
"stable",
"Filesystem /",
"menu pnp",
"CRIT - 96.0% used (207.27 of 215.81 GB), (warn/crit at 80.00/90.00%), trend: +217.07 MB / 24 hours",
"119 min",
"30 sec",
"96%"
],
...Wenn das Skript, das die URL abruft, direkt in der Monitoring-Instanz läuft, können Sie das Automationspasswort für den Benutzer direkt aus dem Dateisystem auslesen.
Das ist keine Sicherheitslücke, sondern so vorgesehen:
Sie können Automatisierungsskripte schreiben, die das Automationspasswort nicht enthalten müssen und keine Konfigurationsdatei benötigen.
Lesen Sie dazu die Datei ~/var/check_mk/web/myuser/automation.secret aus:
OMD[mysite]:~$ cat var/check_mk/web/automation/automation.secret
a8075a39-e7fe-4b5c-9daa-02635In der Shell können Sie den Inhalt dieser Datei leicht in einer Variable speichern, um diese später z.B. per Skript auszulesen:
OMD[mysite]:~$ SECRET=$(cat var/check_mk/web/automation/automation.secret)
OMD[mysite]:~$ echo "$SECRET"
a8075a39-e7fe-4b5c-9daa-026359. Automatische Anmeldung über die URL
|
Die im Folgenden beschriebene automatische Anmeldung über die URL im Browser ist seit Checkmk 2.2.0 aus Sicherheitsgründen deaktiviert, da die per URL übergebenen Zugangsdaten (Benutzername und Passwort) in den Log-Dateien des instanzspezifischen Apache gespeichert werden (siehe Werk #14261). Falls Sie die automatische Anmeldung über die URL trotz dieses Sicherheitsrisikos nutzen wollen, müssen Sie dies explizit aktivieren mit der globalen Einstellung Setup > General > Global settings > User interface > Login via GET requests. |
Wie Sie gesehen haben, können Sie mit Automationsbenutzern beliebige URLs ohne Anmeldung skriptgesteuert abrufen. In Situationen, die ein echtes Login im Browser benötigen, funktioniert dies jedoch nicht, da die Logindaten bei enthaltenen Links (z.B. zu Bildern und Iframes) nicht weitergereicht werden.
Das beste Beispiel dafür ist der Wunsch, einen Monitor an die Wand zu hängen, der ständig ein bestimmtes Dashboard von Checkmk zeigt. Der Monitor soll von einem Rechner angesteuert werden, der beim Starten automatisch den Browser öffnet, sich an Checkmk anmeldet und das Dashboard aufruft.
Um so etwas zu realisieren, legen Sie sich am besten zunächst dafür einen speziellen Benutzer an. Die Rolle Guest user ist dafür gut geeignet, weil diese alle Leserechte einräumt, aber keine Veränderungen oder Eingriffe zulässt.
Die URL für eine automatische Anmeldung konstruieren Sie wie folgt:
Beginnen Sie mit:
http://mycmkserver/mysite/check_mk/login.py?_origtarget=Ermitteln Sie die eigentlich anzuzeigende URL (z.B. die des Dashboards) mit Ihrem Browser — am besten ohne Navigation, was durch Abschalten von Display > Show page navigation geht.
Hängen Sie diese URL an, wobei Sie alles vor dem Teil
/mysite/weglassen.Fügen Sie an die URL die beiden Variablen
_usernameund_passwordan und zwar in folgender Form:&_username=myuser&_password=mysecret.Fügen Sie noch ein
&_login=1an.
Hier ist ein Beispiel für so eine URL:
http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1Beachten Sie:
Ersetzen Sie im Beispiel die Werte
mycmkserver,mysite,myuserundmypassworddurch die bei Ihnen gültigen Werte. Alsmyuserkönnen Sie nicht den Automationsbenutzer verwenden, da für ihn eine Anmeldung über die GUI nicht erlaubt ist.Kommen die Sonderzeichen
&oder%in einem dieser Werte oder in dem Wert von_origtargetvor, müssen Sie diese wie folgt ersetzen:&durch%26und%durch%25.
Testen Sie das Ganze, indem Sie sich in Ihrem Browser von Checkmk abmelden und dann die konstruierte URL in die Adresszeile Ihres Browsers kopieren. Sie müssen dann direkt auf die Zielseite gelangen — ohne Anmeldedialog. Gleichzeitig werden Sie dabei angemeldet und können in der Seite enthaltene Links direkt aufrufen.
Sie können die fertige URL auch mit curl auf der Kommandozeile ausprobieren.
Wenn Sie alles richtig gemacht haben, bekommen Sie als Ergebnis den HTTP-Status-Code 302 FOUND und eine Weiterleitung auf die angegebene Location, wie in der folgenden gekürzten Ausgabe:
OMD[mysite]:~$ curl -v 'http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1'
...
< HTTP/1.1 302 FOUND
...
< Location: /mysite/check_mk/dashboard.py?name=mydashboard
...Sollten Sie im Browser trotz dieser Erfolgsmeldung nicht die gewünschte Ansicht bekommen, prüfen Sie die unter Location angegebene URL — auch wenn diese falsch ist, liefert curl den HTTP-Status-Code 302 FOUND.
Bei falschen Login-Daten bekommen Sie den HTTP-Status-Code 200 OK,
sehen aber lediglich den HTML-Code der Anmeldeseite, wie in der folgenden erneut gekürzten Ausgabe:
OMD[mysite]:~$ curl -v 'http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=NOT&_login=1'
...
< HTTP/1.1 200 OK
...
<!DOCTYPE HTML>
<html><head><meta content="text/html; ...
...
</script>
<script type="text/javascript">
cmk.visibility_detection.initialize();
</script>
</body></html>10. Berechtigungen für Ordner vergeben
10.1. Bedeutung der Rolle Normal monitoring user
Wenn Sie eine etwas größere Monitoring-Umgebung zu verwalten haben, dann möchten Sie sicher auch Mit-Administratoren in die Konfiguration und insbesondere in das Verwalten von Hosts und Services mit einbeziehen. Damit Sie die Kontrolle darüber behalten, wer was ändern darf und damit sich die Leute nicht in die Quere kommen, können Sie Berechtigungen für das Checkmk Setup auf der Basis von Ordnern vergeben.
Der erste Schritt dazu ist, dass Ihre Administrator-Kollegen mit eigenen Benutzern arbeiten, die auf der Rolle Normal monitoring user basieren.
Diese Rolle hat grundsätzlich eine Berechtigung für die Konfigurationsumgebung, allerdings mit einigen wichtigen Einschränkungen:
Es sind lediglich Änderungen an Hosts, Services, Regeln und BI-Aggregaten erlaubt.
Hosts, Services und Regeln können nur in freigegebenen Ordnern verwaltet werden.
BI-Aggregate können nur in freigegebenen BI-Paketen verwaltet werden.
Alles, was globale Auswirkungen hat, ist nicht erlaubt.
Solange Sie noch keine Ordner oder BI-Pakete freigegeben haben, bedeutet das, dass die Benutzer der Rolle Normal monitoring user zunächst keinerlei Änderungen machen können. Das abgespeckte Setup-Menü sieht für normale Monitoring-Benutzer so aus:
10.2. Benutzern das Verwalten von Hosts ermöglichen
Die Berechtigung für das Erstellen, Editieren und Entfernen von Hosts erhält ein Benutzer über Kontaktgruppen. Der Ablauf ist wie folgt:
Nehmen Sie den Benutzer in eine Kontaktgruppe auf.
Bestimmen Sie einen oder mehrere Ordner, für die der Benutzer berechtigt sein soll.
Aktivieren Sie die Eigenschaft Permissions dieser Ordner und wählen Sie die Kontaktgruppe hier aus.
Das folgende Beispiel zeigt die Eigenschaften eines Ordners, in dem alle Benutzer der Kontaktgruppe Linux Hosts verwalten dürfen.
Dabei ist die Option aktiviert, dass dies auch in Unterordnern erlaubt sein soll.
Ob Sie die Hosts automatisch in die Kontaktgruppe aufnehmen möchten, bleibt Ihnen überlassen.
In diesem Beispiel ist die Option Add these groups as contacts to all hosts in this folder nicht gesetzt und die Hosts werden somit auch nicht in die Kontaktgruppe Linux aufgenommen.
Damit sind sie in der Monitoring-Umgebung dann für die Kontaktgruppe Linux nicht sichtbar (solange dies nicht eine Regel erledigt).
Wie Sie sehen, sind also die Sichtbarkeit (und Zuständigkeit im Monitoring) und die Berechtigung für die Konfigurationsumgebung getrennt regelbar.
11. Passwörter
11.1. Sicherheit von Passwörtern
Sicherheit wird heutzutage hoch aufgehängt. Daher gibt es in manchen Unternehmen generelle Vorgaben, wie mit Passwörtern umgegangen werden soll. Checkmk bietet etliche Einstellungen, um solche Vorgaben zu erzwingen. Einen Teil davon finden Sie unter Global settings > User management > Password policy for local accounts:
Die erste Option Minimum password length soll die Qualität des Passworts sicherstellen.
Für die zweite Option Number of character groups to use gibt es insgesamt vier Zeichengruppen:
Kleinbuchstaben
Großbuchstaben
Ziffern
Sonderzeichen
Tragen Sie hier eine 4 ein, so muss ein Passwort aus jeder der genannten Gruppen mindestens ein Zeichen enthalten.
Bei einer 2 ist zumindest sichergestellt, dass das Passwort nicht z.B. nur aus Kleinbuchstaben besteht.
Diese Einstellungen werden bei jeder Änderung des Passworts überprüft.
Die dritte Option Maximum age of passwords zwingt den Benutzer, in regelmäßigen Abständen sein Passwort zu ändern. Sobald es soweit ist, führt der nächste Seitenzugriff den Benutzer zu folgender Eingabeaufforderung:
Erst nach einer Änderung seines Passworts darf der Benutzer weitermachen.
Sie können eine Änderung des initialen Passworts gleich beim ersten Login vorschreiben. Dazu dient die Option Enforce change: Change password at next login or access im Abschnitt Security in den Eigenschaften des jeweiligen Benutzers.
11.2. Richtlinien für die Anmeldung
Unter Global settings > User management finden Sie noch weitere globale Einstellungen, welche die Anmeldung von Benutzern betreffen.
Sperrung nach fehlerhaften Anmeldungen
Mit der globalen Einstellung Lock user accounts after N logon failures können Sie ein Konto nach einer Reihe von fehlerhaften Anmeldeversuchen sperren:
Ein Entsperren ist dann nur noch durch einen Benutzer mit der Rolle Administrator möglich.
Als Administrator können Sie andere Benutzer über Setup > Users > Users und dann die Eigenschaften des gesperrten Benutzers wieder entsperren.
Beachten Sie allerdings, dass auch die Administratorkonten gesperrt werden können!
Sollten Sie als Admin endgültig ausgesperrt sein, so können Sie Ihr Konto nur noch auf der Kommandozeile entsperren.
Editieren Sie dazu als Instanzbenutzer die Datei ~/etc/htpasswd und entfernen Sie in der Zeile des betroffenen Benutzers, hier myuser, das Ausrufezeichen:
OMD[mysite]:~$ cat etc/htpasswd
agent_registration:$2y$12$83XzYwtQJVFizC...
automation:$2y$12$zKF4Sasws7rDJCByZ1r5ke...
cmkadmin:$2y$12$ZmE96frGSm9sdWiWRXtxbuyu...
myuser:!$2y$12$8FU93yH7TFTyJsyUvKCh1eqYJG..
OMD[mysite]:~$ vim etc/htpasswd
...
OMD[mysite]:~$ cat etc/htpasswd
agent_registration:$2y$12$83XzYwtQJVFizC...
automation:$2y$12$zKF4Sasws7rDJCByZ1r5ke...
cmkadmin:$2y$12$ZmE96frGSm9sdWiWRXtxbuyu...
myuser:$2y$12$8FU93yH7TFTyJsyUvKCh1eqYJG...
Dann können Sie sich wieder anmelden.
Automatisches Abmelden
Mit der globalen Einstellung Session management können Sie zwei verschiedene Formen der Beendigung einer Sitzung einstellen und diese auch miteinander kombinieren: einerseits abhängig von der Sitzungsdauer, andererseits abhängig von der Benutzertätigkeit.
Maximum session duration sorgt für ein automatisches Beenden der Sitzung (session) nach einer festgesetzten Zeitspanne. Damit reduzieren Sie unter anderem das Risiko einer Fremdnutzung der Sitzung, da diese nicht unendlich lange aktiv bleibt:
Nach Ablauf der eingestellten Sitzungsdauer muss sich der Benutzer neu anmelden, unabhängig davon, ob er zum Sitzungsende aktiv war oder nicht. Gleichzeitig können Sie über Advise re-authentication before termination angeben, wann der Benutzer vor der "harten" Beendigung seiner Sitzung darauf hingewiesen werden soll, seine Eingaben zu sichern, sich abzumelden und erneut anzumelden:
Die Einstellung Set an individual idle timeout sorgt dafür, dass eine Sitzung beendet wird, wenn ein Benutzer längere Zeit die GUI nicht aktiv verwendet, also z.B., wenn er seinen Arbeitsplatz zeitweise verlassen hat ohne sich in Checkmk abzumelden. Dieser Timeout kann durch aktives Verwenden der GUI aufgehalten werden. Es reicht dabei aber nicht, nur eine Ansicht geöffnet zu haben, die sich selbst regelmäßig neu lädt.
Verhinderung von Mehrfachanmeldungen
Die Einstellung Limit login to single session at a time verhindert, dass ein Benutzer sich mit zwei Browsern parallel an Checkmk anmeldet:
Diese Option ist gleichzeitig mit einem Timeout für einen automatischen Logout bei Untätigkeit verknüpft. Dies ist auch sinnvoll. Nehmen wir an, Sie haben an Ihrem Arbeitsplatz vergessen, sich abzumelden, bevor Sie den Browser schließen. Ohne einen Timeout wäre es Ihnen in diesem Fall nicht möglich, sich während der Bereitschaft von zu Hause aus anzumelden, denn das Schließen des Browsers oder das Herunterfahren des Rechners löst keine Abmeldung aus!
Bei dem Versuch einer parallelen zweiten Anmeldung sehen Sie dann folgenden Fehler:
Die Anmeldung kann in diesem Fall nur durchgeführt werden, wenn Sie die bestehende Sitzung aktiv beenden oder den eingestellten Timeout abwarten.
11.3. Zwei-Faktor-Authentifizierung
Um die Absicherung Ihrer Checkmk-Instanzen zu verbessern, bietet Checkmk die Nutzung einer Zwei-Faktor-Authentifizierung für jeden Benutzer an. Diese Zwei-Faktor-Authentifizierung basiert auf dem Internetstandard FIDO2/WebAuthn. Authentifiziert wird klassisch auf Basis von Wissen (Passwort) und Besitz (Authentifikator).
Sie können jede von Browser und Betriebssystem unterstützte FIDO2-kompatible Hardware verwenden. Am weitesten verbreitet sind USB- oder NFC-Token wie der YubiKey. Alternativ ist die Nutzung von Authenticator-Apps (z.B. auf dem Smartphone) möglich, die ein zeitabhängiges Einmalpasswort (oder time-based one-time password (TOTP)) generieren.
Voraussetzungen für den Checkmk-Server
Durch die Vorgaben des WebAuthn-Standards ergeben sich für den Einsatz der Zwei-Faktor-Authentifizierung drei Voraussetzungen:
Die Checkmk-Weboberfläche ist mit HTTPS abgesichert.
Die Webadresse wird als einfacher Host-Name oder als voll qualifizierter Domainname angegeben — auf jeden Fall als eine gültige Domainadresse.
Die URL wird durchgängig im gleichen Format eingegeben, also beispielsweise immer
https://www.mycompany.com/mysite.
Einrichtung
Rufen Sie die Zwei-Faktor-Authentifizierung über das User-Menü auf:
Sie erhalten nun zwei mit dem Schlüsselsymbol 
gekennzeichnete Möglichkeiten, den zweiten Faktor hinzuzufügen:
Register authenticator app für die Konfiguration einer App, die Einmalpasswörter generiert, und Register security token für die Verwendung eines Hardware-Token.
Checkmk erkennt die auf Ihrem Computer verfügbaren Authentifizierungsmöglichkeiten. Es öffnet sich ein kleiner Dialog im Browserfenster, in dem Sie den Authentifikator festlegen. Bei Verwendung eines Hardware-Tokens ist die Einrichtung mit der Berührung des Knopfes abgeschlossen. Bei Nutzung von Einmalpasswörtern scannen Sie zuerst den angezeigten QR-Code mit der Authenticator-App und geben zur Bestätigung einen Code ein, den Sie mit der App erzeugen. Die Sitzung wird in beiden Fällen nahtlos weitergeführt.
Anmeldung
Bei künftigen Anmeldeversuchen ist dann die Zwei-Faktor-Authentifizierung in Checkmk aktiv. Zuerst geben Sie, wie gewohnt, Ihren Benutzernamen und das Passwort ein. Dann erscheint ein zweiter Anmeldedialog:
Nach der Aktivierung des Authentifikators können Sie wie gewohnt mit Checkmk arbeiten.
Backup-Codes erstellen und nutzen
Für den Fall, dass Sie Ihren Authentifikator einmal nicht zur Hand haben, können Sie alternativ einen Backup-Code eingeben.
Erstellen Sie sich dazu vorab auf der Seite User > Two-factor authentication mit Hilfe von 
Generate backup codes eine Liste mit Backup-Codes:
Verwahren Sie diese an einem sicheren Ort.
Nachdem Sie Backup-Codes generiert haben, wird im zweiten Anmeldedialog Two-factor authentication die zusätzliche Option Use backup code angezeigt. Klicken Sie darauf, wenn Sie sich bei Checkmk mit einem Backup-Code anmelden wollen. Der zweite Anmeldedialog wird ersetzt, so dass Sie dort einen Backup-Code eingeben können:
Als Administrator die Zwei-Faktor-Authentifizierung prüfen und aufheben
Als Administrator sehen Sie in der Benutzerverwaltung (Setup > Users > Users) anhand des Eintrags in der Spalte Authentication, welche Benutzer eine Zwei-Faktor-Authentifizierung eingerichtet haben.
Hat nun einer dieser Benutzer keinen Zugang mehr zu Checkmk, also z.B. seinen Token verloren oder beschädigt, so können Sie die Zwei-Faktor-Authentifizierung gezielt für diesen Benutzer entfernen.
Öffnen Sie dazu in der Benutzerverwaltung den betreffenden Eintrag mit einem Klick auf .
Die Zwei-Faktor-Authentifizierung für diesen Benutzer entfernen Sie mit User > Remove two-factor authentication.
Nach Ihrer Zustimmung im Bestätigungsdialog kann sich der Benutzer wieder "nur" mit Benutzernamen und Passwort an der Weboberfläche von Checkmk anmelden.
Als Administrator die Zwei-Faktor-Authentifizierung erzwingen
Wie Sie im Abschnitt Einrichtung gelesen haben, kann jeder Benutzer die Zwei-Faktor-Authentifizierung für das eigene Checkmk-Konto aktivieren. Als Administrator haben Sie die Möglichkeit, diese Freiwilligkeit zu einer Verpflichtung zu machen. Sie können die Zwei-Faktor-Authentifizierung für alle Benutzer einer Rolle oder sogar für alle Benutzer erzwingen — mit der Option Enforce two factor authentication.
Um die Zwei-Faktor-Authentifizierung für eine Rolle zu erzwingen, öffnen Sie Setup > Users > Roles & permissions, klicken Sie auf das Stiftsymbol der Rolle und aktivieren Sie in Basic properties die Checkbox Enforce two factor authentication.
Für alle Checkmk-Benutzer finden Sie diese Option in Setup > General > Global settings > User management.
Die Aktivierung als globale Einstellung setzt eine rollenbasierte Einstellung außer Kraft.
Ein Benutzer, der die Zwei-Faktor-Authentifizierung aktivieren soll, aber noch nicht hat, wird bei der Anmeldung nach Eingabe von Benutzername und Passwort auf die Seite Two-factor authentication geleitet:
Erst nach der Einrichtung einer der beiden angebotenen Möglichkeiten für den zweiten Faktor wird der Benutzer zur Checkmk-Benutzeroberfläche weitergeleitet.
11.4. Passwort auf der Kommandozeile ändern
Sie können im Notfall ein Passwort auch per Kommandozeile ändern.
Das rettet Sie in dem Fall, in dem Sie das Passwort von cmkadmin verloren haben.
Voraussetzung ist natürlich, dass noch eine Anmeldung als Linux-Benutzer auf dem Checkmk-Server möglich ist und Sie mit omd su mysite Instanzbenutzer werden können.
Die Passwörter sind in der Datei ~/etc/htpasswd gespeichert, wie bereits weiter oben beschrieben.
Das Ändern geschieht mit dem Befehl cmk-passwd.
Dieser fragt Sie nicht nach dem bestehenden Passwort.
cmk-passwd wird in einer aktuellen Version von Checkmk immer eine sichere Verschlüsselungsmethode wählen, um Ihre Passwörter zu speichern.
Aktuell verwendet cmk-passwd dafür bcrypt.
Unverschlüsselte und schwach verschlüsselte Passwörter (bspw. mit MD5) erlauben keine Anmeldung an der GUI.
OMD[mysite]:~$ cmk-passwd cmkadmin
New password: secret
Re-type new password: secret12. Benutzerdefinierte Attribute
Für die Benachrichtigung von Benutzern steht Ihnen neben dem Feld für die E-Mail-Adresse noch das Feld Pager address zur Verfügung. Wenn Ihnen das nicht ausreicht und Sie noch mehr Informationen zu einem Benutzer speichern möchten, können Sie über Setup > Users > Custom user attributes > Add attribute eigene Felder erzeugen, die dann pro Benutzer individuell mit Werten gefüllt werden können.
Das Anlegen eines neuen solchen Attributs bringt Sie zu folgendem Dialog:
Wie immer ist die ID (Name) später nicht änderbar, der Titel (Title) aber schon. Das Topic legt fest, in welchen Abschnitt der Benutzereinstellungen das neue Feld einsortiert wird. Ferner können Sie entscheiden, ob Benutzer das Feld selbst editieren können (es wird dann in ihren persönlichen Einstellungen auftauchen) und ob der Wert direkt in der Benutzertabelle im Setup angezeigt werden soll.
Nur wenn Sie die Checkbox bei Make this variable available in notifications aktivieren, können Sie diesen Wert auch bei Benachrichtigungen verwenden. Denn dazu muss der Wert dem Monitoring-Kern (z.B. CMC) in einer Variablen (ein sogenanntes „Custom macro“) bekannt gemacht werden.
Der Name der benutzerdefinierten Variable wird aus der von Ihnen gewählten ID abgeleitet.
Diese wird in Großbuchstaben umgewandelt und es wird ein CONTACT_ vorangestellt.
Aus einem phone wird dann also CONTACT_PHONE.
Beachten Sie, dass beim Übergeben der Variable über Umgebungsvariablen dann nochmal ein NOTIFY_ vorangestellt wird.
Bei Ihrem eigenen Benachrichtigungsskript kommt die Variable dann also als NOTIFY_CONTACT_PHONE an.
13. Meldungen an Benutzer schreiben
Im Artikel über Benachrichtigungsregeln gehen wir sehr ausführlich darauf ein, wie Checkmk die Kontakte über Probleme bei Hosts oder Services informieren kann. Manchmal möchten Sie aber vielleicht alle Benutzer (auch solche, die keine Kontakte sind) über Organisatorisches in eigener Sache informieren — z.B. über eine Wartung des Checkmk-Systems selbst.
Für solche Zwecke bietet Checkmk ein kleines eingebautes Meldungstool, das völlig getrennt von den Benachrichtigungen funktioniert. Das Tool finden Sie über Setup > Users und dort in Users > Send user messages. Hier haben Sie die Möglichkeit, eine Meldung an alle (oder manche) Ihrer Benutzer zu schreiben.
Dabei haben Sie die Wahl zwischen vier Meldungsarten:
Show popup message |
Beim nächsten Seitenaufruf des Benutzers wird ein Popup-Fenster mit der Nachricht geöffnet. |
Show hint in the 'User' menu |
Der Benutzer wird durch ein Zahlensymbol im User-Menü der Navigationsleiste auf die Nachricht hingewiesen. |
Send email |
Versendet eine E-Mail. Damit erreichen Sie aber nur Benutzer, bei denen auch eine E-Mail-Adresse konfiguriert ist. |
Show in the dashboard element 'User messages' |
Die Nachricht wird in einem Dashlet des Typs User messages angezeigt. |
Mit Message expiration können Sie noch nicht abgerufene Meldungen einfach löschen, sobald diese nicht mehr relevant sind.
Eine Besonderheit der Option Show hint in the 'User' menu: Über User messages > Received messages finden Nutzer ihre gesammelten Nachrichten und können sie quittieren und/oder löschen.
Checkmk benachrichtigt von sich aus Benutzer über bestimmte sicherheitsrelevante Änderungen an deren Konten. Das sind unter anderem Änderungen des Passworts und an der Zwei-Faktor-Authentifizierung (Aktivierung, Deaktivierung, Anmeldung per Backup-Code, Erstellung und Widerruf von Backup-Codes). Sofern eine E-Mail-Adresse für den Benutzer hinterlegt ist, erfolgen die Meldungen per E-Mail, sonst über das Meldungstool.
Sicherheitsmeldungen werden nur durch Aktionen innerhalb der Checkmk-GUI ausgelöst. Sie können vom Benutzer nicht gelöscht werden, jedoch kann die Anzeigedauer dieser Benachrichtigungen konfiguriert werden über Setup > General > Global settings > User management > User security notification duration. Standardmäßig beträgt die Anzeigedauer 7 Tage.
14. Weiterführende Themen
Checkmk beherrscht noch weitere Spielarten der Anmeldung:
Anbindung von LDAP/Active Directory
Authentifizierung mit SAML
Authentifizierung mit Kerberos
Authentifizierung in einem Aufbau mit Reverse-Proxy
Authentifizierung mit HTTP Basic Authentication
15. Dateien und Verzeichnisse
Folgende Aufstellung zeigt Ihnen, welche Dateien und Verzeichnisse auf dem Checkmk-Server mit der Benutzerverwaltung zu tun haben.
Wie immer sind alle Angaben hier relativ zum Instanzverzeichnis (z.B. /omd/sites/mysite).
| Pfad | Bedeutung |
|---|---|
|
Passwörter der Benutzer im Apache- |
|
Diese Datei enthält ein zufälliges Geheimnis, mit dem Anmelde-Cookies signiert werden.
In verteilten Umgebungen soll diese Datei in allen Instanzen gleich sein — und ist dies auch, wenn Sie alles mit der Weboberfläche einrichten.
Wird diese Datei geändert, so werden alle Anmeldungen sofort ungültig und Benutzer müssen sich neu anmelden.
Diese Datei ist mit den Rechten |
|
Seriennummern der Passwörter pro Benutzer. Jede Änderung des Passworts erhöht die Seriennummer und macht damit alle aktuellen Sitzungen ungültig. Damit ist sichergestellt, dass eine Passwortänderung einen Benutzer zuverlässig abmeldet. |
|
Enthält die mit der Konfigurationsumgebung eingerichteten Benutzer. Hier sind nur diejenigen Daten über die Benutzer gespeichert, die sich rein mit der GUI befassen. Manuelle Änderungen in dieser Datei werden sofort wirksam. |
|
Kontaktinformationen der mit der Konfigurationsumgebung eingerichteten Benutzer.
Hier sind alle Daten abgelegt, die für die Konfiguration des Monitoring-Kerns relevant sind.
Nur Benutzer, die auch Kontakte sind, sind hier aufgeführt.
Damit manuelle Änderungen hier wirksam werden, muss die neue Konfiguration in den Kern geladen werden — z.B. mit |
|
Jeder Benutzer, der sich mindestens einmal an der GUI angemeldet hat, hat hier ein Unterverzeichnis, in dem Dinge wie selbst erstellte Ansichten und Berichte, die aktuelle Konfiguration der Seitenleiste und vieles anderes in einzelnen kleinen Dateien mit der Endung |
|
Log-Datei der Benutzeroberfläche. Hier finden Sie Fehlermeldungen bezüglich Authentifizierung und LDAP-Anbindung. |