Benutzer, Zuständigkeiten, Berechtigungen

Die Benutzerverwaltung finden Sie unter Setup > Users > Users. In einer frisch angelegten Instanz sieht diese Seite so aus (Auszug):

Sie sehen hier den einzigen Benutzer cmkadmin, welcher automatisch beim Erzeugen der Instanz angelegt wurde. Bei der Checkmk-Appliance kann dieser Benutzer anders heißen, da Sie dessen Namen und Passwort selbst festlegen. Dieser erste Benutzer hat folgende Eigenschaften:

Das Formular zum Anlegen eines neuen Benutzers mit oder zum Editieren eines bestehenden Benutzers mit ist in fünf Abschnitte unterteilt. Im ersten geht es um die 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 Authorized 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 autorisierten Instanzen kontaktieren, um Ansichten aufzubauen — was wiederum der Performanz enorm zugutekommt.

Der zweite Kasten dient der Anmeldung und Berechtigung. Die Option Automation secret for machine accounts ist für Konten gedacht, die skriptgesteuert per HTTP 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 drei vordefinierten Rollen (siehe weiter unten) 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.

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.

Im Kasten Notifications können Sie über die Option Receive fallback notifications festlegen, dass dieser Kontakt Benachrichtigungen bekommt, wenn keine Benachrichtigungsregel greift.

Alle Einstellungen in diesem Kasten kann der Benutzer über User > Edit profile auch selbst ändern (außer in der Rolle guest). 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 Onlinehilfe.

Auch die Oberflächeneinstellungen können Benutzer selbst über User > Edit profile anpassen. Besonders interessant ist die Option Set custom show mode 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.

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 vier angelegten 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.

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.

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:

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.

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:

Die Tatsache, dass ein normaler Benutzer (Rolle 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 admin) 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 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 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:

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 umstellen über Global settings > Monitoring Core > Authorization settings. Wenn Sie dort Hosts 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).

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.

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 drei vordefinierten Rollen ausgeliefert, welche niemals gelöscht, aber beliebig angepasst werden können:

Die Rollen werden über Setup > Users > Roles & permissions verwaltet:

Übrigens: Beim Erzeugen einer neuen Checkmk-Instanz wird nur ein Benutzer der Rolle admin angelegt (cmkadmin). Die beiden anderen Rollen werden erst mal nicht verwendet. Wenn Sie einen Gastbenutzer wünschen, müssen Sie diesen selbst anlegen.

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 Onlinehilfe.

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 Defaultwert ä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.

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 admin, user und guest die neue Berechtigung enthalten sein soll. Da jede Ihrer eigenen Rollen von genau einer der drei 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 user-Rolle 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.

Wenn Sie die Berechtigungen in den einzelnen Rollen vergleichen möchten, hilft die Matrixansicht, zu erreichen über Setup > Users > Roles & permissions > Permission matrix. Der Menüeintrag erzeugt folgende Darstellung, 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.

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 user basieren.

Diese Rolle hat grundsätzlich eine Berechtigung für die Konfigurationsumgebung, allerdings mit einigen wichtigen Einschränkungen:

Solange Sie noch keine Ordner oder BI-Pakete freigegeben haben bedeutet das, dass die Benutzer der Rolle user zunächst keinerlei Änderungen machen können! Das abgespeckte Setup-Menü der Navigationsleiste sieht für normale Benutzer so aus:

Die Berechtigung für das Anlegen, Editieren und Entfernen von Hosts erhält ein Benutzer über Kontaktgruppen. Der Ablauf ist wie folgt:

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.

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:

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.

Unter Global settings > User management finden Sie noch weitere globale Einstellungen, welche die Anmeldung von Benutzern betreffen.

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 htpasswd, der aus der Apache-Installation kommt. Dieser fragt Sie nicht nach dem bestehenden Passwort. Wir empfehlen, dass Sie ihr Passwort durch Verwendung der Option -m mithilfe von MD5 verschlüsseln. Unverschlüsselte oder mit bcrypt verschlüsselte Passwörter erlauben derzeit keinen Login in die GUI.