Benutzer, Zuständigkeiten, Berechtigungen

Letzte Aktualisierung: 12. September 2016


1. Einleitung

In diesem Artikel zeigen wir Ihnen alles rund um Benutzerverwaltung und Berechtigungen in Check_MK. Doch bevor wir in die Details gehen können, müssen wir erst einige Begriffe klären.

Ein Benutzer (User) ist in Check_MK jemand, der Zugang zur Benutzeroberfläche hat. Er hat eine oder meh­rere 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 Statusoberfläche und wird eventuell über Probleme alarmiert.

Es gibt auch Benutzer, die keine Kontakte sind. Ein Beispiel dafür ist omdadmin (cmkadmin ab 1.4.0), der beim Erzeugen einer Instanz automatisch angelegt wird. Dieser darf zwar alle Hosts und Services sehen, aber nur, weil in seiner Rolle admin 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 Alarmierung angelegt wurde (z. B. zur Weiterleitung von Alarmen 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 Linuxhosts 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 Privilegien jemand hat.

2. Benutzerverwaltung über WATO

Die Benutzerverwaltung finden Sie im WATO-Modul Users. In einer frisch angelegten Instanz sieht diese Seite so aus:

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

  • Er hat die Rolle Administrator (admin) und damit alle Berechtigungen!
  • Er ist für nichts Kontakt und bekommt keine Alarme.
  • Er darf trotzdem alles sehen (wegen seiner Rolle admin).
  • Das Standardpasswort sollten Sie dringend ändern!

An der Titelzeile sehen Sie übrigens immer, als wer Sie gerade angemeldet sind und welche Rolle Sie haben:

Die Maske zum Anlegen eines neuen Benutzers mit oder zum Editieren eines bestehenden Benutzers mit ist in vier Abschnitte unterteilt. Im ersten geht es um die Identität:

Identität

Wie immer in Check_MK 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 Email-Adresse ist optional und nur dann notwendig, wenn der Benutzer ein Kontakt werden soll, der per Email alarmiert werden soll. Analog ist das Feld Pager address für die Alarmierung per SMS oder ähnliche Systeme vorgesehen. Wenn Sie eigene Alarmierungsskripte schreiben, können Sie auf die Werte in den Feldern zugreifen und sie für beliebige Zwecke verwenden.

Sicherheit

Der zweite Kasten dient der Anmeldung und Berechtigung. Die Option Automation secret for machine accounts ist für Accounts gedacht, die skriptgesteuert per HTTP auf Check_MK 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 meh­rere Rollen geben. Er bekommt dann die Rechte von allen diesen Rollen. Mit den drei vordefinierten Rollen (siehe weiter unten) macht dies 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 im System erhalten. Falls er ein Kontakt ist, ist auch die Alarmierung von der Sperre nicht beeinflusst und er wird weiterhin Emails etc. erhalten. War der Benutzer zum Zeitpunkt der Sperrung gerade angemeldet, so wird er automatisch abgemeldet.

Kontaktgruppen

Sobald Sie einen Benutzer einer oder mehreren Kontaktgruppe zuordnen wird dieser zum Kontakt. Bei einer neuen Instanz wird automatisch die Kontakt­gruppe Everything angelegt, die immer alle Hosts und alle Services enthält (in früheren Versionen hieß diese Gruppe Everbody, wurde aber wegen der irreführenden Bezeichnung geändert). Ein Benutzer in dieser Gruppe ist automatisch für alle Hosts und Services zuständig.

Persönliche Einstellungen

Alle Einstellungen im letzten Kasten kann der Benutzer über 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.

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 mit dem WATO-Modul 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 erstmal leer in doppelter Hinsicht: Sie enthält weder Kontakte noch Hosts oder Services. Die Zuordnung von Kontaktgruppen zu Kontakten geschieht über die Benutzerprofile, wie wir schon beim Editieren des Benutzers gesehen haben. Die Zuordnung von Hosts und Services geschieht wie folgt:

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 den Knopf während Sie im Ordner sind. Dort finden Sie die Option Permissions. Aktivieren Sie diese Checkbox, um zur Auswahl der Kontakt­gruppen zu kommen:

Der eigentliche Sinn dieser Option ist das Setzen von Berechtigungen für das Pflegen von Hosts in WATO, welches wir weiter unten im Detail besprechen. Sobald Sie Berechtigungen für bestimmte Kontaktgruppen vergeben, können Sie diese im gleichen Zug auch als Kontaktgruppen für die Hosts im Monitoring eintragen lassen. Dabei können Sie entscheiden, ob diese auch für Hosts in Unterordnern gelten sollen und auch, ob die Services der Hosts ebenfalls explizit diese Gruppen bekommen sollen. Services ohne explizite Zuweisung erben nämlich alle Gruppen eines Hosts, auch solche, die durch Regeln zugewiesen wurden.

Achtung: 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 in all subfolders 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 schnellen Zugriff auf den dafür nötigen Regelsatz Assignment of hosts to contact groups erreichen Sie vom WATO-Modul der Kontaktgruppen aus bequem mit dem Knopf . In diesem Regelsatz finden Sie eine vordefinierte Regel, die beim Erzeugen der Instanz angelegt wurde und welche alle Hosts der Kontaktgruppe Everything zuweist.

Bitte 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 Kontakt­gruppen zuordnen – unabhängig von den Gruppen des Hosts. Dabei gelten folgende Regeln:

  • Wenn einem Service keine Kontaktgruppe zugordnet 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.

Kontrolle der Zuordnung

Ob Sie alle Regeln und Ordner richtig konfiguriert haben, können Sie in den Details eines Hosts oder Services in der Statusoberfläche überprüfen. Dort finden Sie die Einträge Contact groups und Contacts, welche die letztendliche Zuordnung für dieses Objekt auflisten.

4. Sichtbarkeit von Hosts und Services

Die Tatsache, dass ein normaler Anwender (Rolle user) nur solche Objekte sieht, für die er ein Kontakt ist, ist umso wichtiger, je größer Ihre Monitoringumgebung ist. Das sorgt nicht nur für Übersicht, sondern verhindert auch, dass Benutzer dort eingreifen, wo sie nichts zu suchen haben.

Als Adminbenutzer (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 nur noch die Hosts und Services sehen, 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 des Monitorings 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 Anwender ist die Sichtbarkeit in der kompletten Statusoberfläche so konsequent durchgezogen, 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:

  • Sämtliche tabellarischen Ansichten von Hosts und Services
  • Die Tactical Overview
  • Dashboards inklusive der „Globen“
  • Berichte, die von dem Benutzer erstellt werden

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 der Kollege, der 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 er für diese keine Alarme!

Wenn Ihnen das nicht gefällt, können Sie das umstellen. Die globale Option dazu heißt Monitoring Core ➳ Authorization settings. Wenn Sie dort Hosts auf Strict - Must be explicit contact of a 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 Alarme bekommen).

Host- und Servicegruppen

Die zweite Einstellung in dieser Option betrifft Host- und Servicegruppen. 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 - must be contact of all members macht alle Gruppen unsichtbar, in denen Sie für mindestens einen Host bzw. Service kein Kontakt sind.

Bitte beachten Sie, dass diese beiden Einstellungen zur Sichtbarkeit keinen Einfluss auf die Alarmierung haben.

5. Alarmierung

Kontaktzuordnungen haben auch einen Einfluss auf die Alarmierung. Check_MK ist so voreingestellt, dass im Falle eines Problems alle Kontakte des betroffenen Hosts oder Services alarmiert werden. Die geschieht durch eine Alarmierungsregel, die bei neuen Instanzen automatisch angelegt wird. Dies ist ein sehr sinnvolles Verhalten.

Trotzdem können Sie bei Bedarf die Regel anpassen oder durch weitere Regeln ergänzen, so dass eine Alarmierung im Extremfall sogar ganz unabhängig von den Kontaktgruppen geschieht. Häufiger Grund dafür ist, dass ein Benutzer sich wünscht, bestimmte Alarme 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 erfahren Sie im Artikel über die Alarmierung.

6. Rollen und Berechtigungen

6.1. Vordefinierte Rollen

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

Check_MK wird mit folgenden drei vordefinierten Rollen ausgeliefert, welche niemals gelöscht, aber beliebig angepasst werden können:

Rolle Berechtigungen Einsatzzweck
admin Alle Berechtigungen – insbesondere das Recht, Berechtigungen zu ändern. Der Check_MK-Administrator, der das Monitoringsystem an sich betreut.
user Darf nur seine Hosts und Services sehen, in WATO nur in für ihn freigegebenen Ordnern Änderungen machen und darf generell nichts machen, was andere Benutzer beeinflusst. Der normale Check_MK-Bentuzer, der das Monitoring nutzt und auf Alarme reagiert.
guest Darf alles sehen aber nichts ändern. Gedacht zum einfachen „Gucken“, wobei sich alle Gäste einen gemeinsamen Account teilen. Auch nützlich für öffentliche Statusbildschirme, die an der Wand hängen.

Die Rollen werden im WATO-Modul Roles & Permissions verwaltet:

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

6.2. Bestehenden Rollen anpassen

Wie üblich gelangen Sie über das Symbol in den Editiermodus für eine Rolle:

Welche Bedeutung die zahlreichen Berechtigungen haben 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 erstmal keinen Unterschied, ob Sie yes oder default (yes) eingestellt haben. Allerdings kann eine neue Version von Check_MK 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 Check_MK-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 eine 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, denn wenn man bedenkt, wieviele 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.

Und das Ableiten löst noch ein weiteres Problem: Da wir Check_MK rege weiterentwickeln, kommen immer wieder neue Berechtigungen hinzu. Jedesmal entscheiden wir dann, in welcher der drei Rollen admin, user und guest die neue Berechtigung enthalten sein soll. Da auch Ihre eigenen Rollen von genau einer von diesen 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.

6.4. Rollen vergleichen mit der Matrixansicht

Wenn Sie die Berechtigungen in den einzelnen Rollen vergleichen möchten, hilft der Knopf . Er 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.

7. Persönliche Einstellungen

Einen kleinen Teil der Benutzereinstellungen kann jeder Benutzer selbst verwalten. Diese finden sich in am Fuß der Seitenleiste hinter dem Knopf . Dieser bringt Sie zu folgende Maske:

Die wichtigste Funktion ist die Änderung des Passworts. Dazu muss der Benutzer nicht nur das neue, sondern auch das bestehende Passwort eingeben. Eine Beschreibung der weiteren Einstellmöglichkeiten finden Sie wie immer in der Onlinehilfe.

Bei einem Verteilten Monitoring werden nach jeder Änderung die neuen Einstellungen sofort auf alle Monitoringinstanzen übertragen. Nur so ist sichergestellt, dass das neue Passwort auch sofort überall funktioniert – und nicht erst beim nächsten Aktivieren der Änderungen. Das klappt allerdings nur für Standorte, die zu diesem Zeitpunkt auch über das Netzwerk erreichbar sind. Alle andere Standorte bekommen die Aktualisierungen beim nächsten erfolgreichen Activate changes.

8. Automationsbenutzer (für Webservices)

Bei der Anbindung von Check_MK 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 in WATO per Web-API
  • Abrufen von Daten aus Ansichten als CSV oder JSON zum Zwecke der Weiterverarbeitung
  • Abrufen des aktuellen Status von BI-Aggregaten, um diese als Service anzulegen

In diesen Situtation muss eine externe Software bestimmte URLs der Check_MK-Oberfläche automatisiert abrufen können. Und da stellt sich natürlich die Frage, wie hier die Benutzeranmeldung geschieht. Der normale Weg über die Loginmaske ist umständlich und erfordert den Abruf von mehreren URLs hintereinander und das Speichern eines Cookies.

Um dies zu vereinfachen, bietet Check_MK 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 stimmte Variablen in der URL.

Sie legen einen Automationsbenutzer wie einen normalen Benutzer an, vergeben aber kein Passwort, sondern ein Geheimnis (Automation secret). Dieses können Sie mit dem Würfel automatisch erstellen lassen:

Ein Automationsuser 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 in der URL folgende Variablen zusätzlich an:

_usernamedie ID des Automationsusers
_secretdessen Automation secret

Hier ist ein Beispiel für den Abruf einer Ansicht im JSON-Format mit dem Automationsbenutzer automation und dem Geheimnis aus der obigen Abbildung:

root@linux# curl 'http://moni01.mycompany.net/mysite/check_mk/view.py?_username=automation&_secret=GLV@GYCAKINOLICMAFVP&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 Geheimnis für den Benutzer direkt aus dem Dateisystem auslesen. Das ist kein Sicherheitsloch, sondern extra so vorgesehen. Damit können Sie Automatisierungsskripte schreiben, die das Geheimnis nicht enthalten müssen und auch keine Konfigurationsdatei benötigen. Lesen Sie dazu einfach die Datei ~/var/check_mk/web/myuser/automation.secret aus:

OMD[mysite]:~$ cat var/check_mk/web/automation/automation.secret
GLV@GYCAKINOLICMAFVP

In der Shell können Sie den Inhalt dieser Datei leicht in einer Variable speichern:

OMD[mysite]:~$ SECRET=$(cat var/check_mk/web/automation/automation.secret)
OMD[mysite]:~$ echo "$SECRET"
GLV@GYCAKINOLICMAFVP

Dies macht sich z. B. auch das Script downtime zunutze, welches Sie in den Treasures von Check_MK finden und mit dem Sie skriptgesteuert Wartungszeiten für Hosts und Services setzen und entfernen können. Wenn der Automationsbenutzer wie bei uns im Beispiel automation heißt, brauchen Sie als einziges Argument den Hostnamen, für den eine Wartung eingetragen werden soll:

OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime myhost123

Weitere Optionen des Skripts erfahren Sie in dessen Onlinehilfe:

OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime --help

9. Automatische Anmeldung über die URL

Wie wir gesehen haben, können Sie mit Automationsbenutzern beliebige URLs ohne Anmeldung skript­gesteuert abrufen. In Situationen, die einen echten Browserlogin 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 Bildschirm an die Wand zu hängen, der ständig ein bestimmtes Dashboard von Check_MK zeigt. Der Bildschirm soll von einem Rechner angesteuert werden, der beim Starten automatisch den Browser öffnet, sich an Check_MK 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 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:

  1. Beginnen Sie mit http://mycmkserver/mysite/login.py?_origtarget=
  2. Ermitteln Sie die eigentlich anzuzeigende URL (z. B. die des Dashboards) mit Ihrem Browser – am besten, in dem Sie mit dem Browser nur das rechte Frame anzeigen und die Seiteleiste weglassen.
  3. Hängen Sie diese URL an, wobei Sie alles vor dem Teil /mysite/... weglassen.
  4. Fügen Sie an die URL die beiden Variablen _username und _password an und zwar in folgender Form: &_username=myuser&_password=mysecret
  5. Fügen Sie noch ein &_login=1 an.

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=1'

Bitte beachten Sie:

  • Ersetzen Sie im Beispiel die Werte mycmkserver, mysite, myuser und mypassword durch die bei Ihnen gültigen Werte.
  • Kommen die Sonderzeichen & oder % in einem dieser Werte oder in dem Wert von _origtarget vor, müssen Sie diese wie folgt ersetzen: & durch %26 und % durch %25.

Testen Sie das Ganze, in dem Sie sich in Ihrem Browser von Check_MK abmelden und dann die konstruierte URL in Ihre Adresszeile vom Browser kopieren. Sie müssen dann direkt auf die Zeilseite gelangen – ohne Anmeldemaske. 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 in „302 Found“ und eine Weiterleitung („The document has moved...“).

OMD[mysite]:~$  curl 'http://localhost/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1'
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head>
<h1>Found</h1>
<p>The document has moved <a href="/heute/check_mk/dashboard.py?name=topology">here</a>.</p>
</body></html>

Bei einem Fehler erhalten Sie den HTML-Code der Anmeldemaske. Dieser endet mit folgendem Code:

<!--
if (document.login._username) {    document.login._username.focus();
    document.login._username.select();
}
// -->
</script>
</body></html>

10. Berechtigungen in WATO

10.1. Bedeutung der Rolle user für WATO

Wenn Sie eine etwas größere Monitoringumgebung zu verwalten haben, dann möchten Sie sicher auch Kollegen 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 in WATO auf der Basis von Ordnern vergeben.

Der erste Schritt dazu ist, dass Ihre Admin-Kollegen mit eigenen Benutzern arbeiten, die auf der Rolle user basieren. Diese Rolle hat grundsätzlich eine Berechtigung für WATO, allerdings mit einigen wichtigen Einschrän­kungen:

  • 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 Mitglieder der Rolle user zunächst keinerlei Änderungen machen können! Das WATO-Elemement der Seitenleiste sieht für normale Anwender so aus:

10.2. Benutzern das Verwalten von Hosts ermöglichen

Das Berechtigen eines Benutzers für das Anlegen, Editieren und Entfernen von Hosts geschieht über Kontaktgruppen. Der Ablauf ist wie folgt:

  1. Nehmen Sie den Benutzer in eine Kontaktgruppe auf.
  2. Bestimmen Sie einen oder mehrere Ordner, für die der Benutzer berechtigt sein soll.
  3. 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 Status­ober­fläche dann für die Kontaktgruppe Linux nicht sichtbar (solange dies nicht eine Regel erledigt). Wie Sie sehen, sind also die Sichtbar­keit (und Zuständigkeit im Monitoring) und die Berechtigung für WATO getrennt regelbar.

11. Passwortänderung, Passwortpolicies

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. Check_MK bietet etliche Einstellungen, um solche Vorgaben zu erzwingen. Einen Teil davon finden Sie in den globalen Einstellungen unter User management ➳ Password policy for local accounts:

Die ersten beiden Einstellungen sollen eine Qualität des Passworts sicherstellen. Für die zweite Einstellung 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 wäre zumindest sichergestellt, dass das Passwort nicht z. B. nur aus Kleinbuchstaben besteht. Diese Einstellungen werden bei jeder Änderung des Passworts überprüft.

Die dritte Einstellung 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 Maske:

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.

11.2. Policies für die Anmeldung

Sperrung nach fehlerhaften Anmeldungen

In den globalen Einstellungen finden Sie unter User management noch weitere Einstellungen, welche die Anmeldung von Benutzern betreffen. Über die Einstellung Lock user accounts after N logon failures können Sie ein Konto nach einer Reihe von fehlerhaften Anmeldungen sperren:

Ein Entsperren ist dann nur noch durch einen Benutzer mit der Rolle admin möglich. Bitte beachten Sie aber, dass auch die Administratorkonten gesperrt werden können! Sollten Sie endgültig ausgesperrt sein, so können Sie Ihr Konto auf der Kommandozeile entsperren. Editieren Sie dazu als Instanzbenutzer die Datei etc/htpasswd und entfernen Sie in der Zeile des betroffenen Nutzers das Ausrufezeichen:

OMD[mysite]:~$ cat etc/htpasswd
omdadmin:!.lwoHWmlCs.HTE
hh:$1$771269$losX.vlIY34TTR6zwiG5s1
OMD[mysite]:~$ vim etc/htpasswd
OMD[mysite]:~$ cat etc/htpasswd
omdadmin:.lwoHWmlCs.HTE
hh:$1$771269$losX.vlIY34TTR6zwiG5s1

Dann können Sie sich wieder anmelden.

Automatisches Abmelden

Eine weitere Einstellung sorgt für ein automatisches Abmelden für den Fall, dass ein Benutzer längere Zeit die GUI nicht verwendet:

Der Timeout wird hierbei nur durch aktives Verwenden der GUI aufgehalten. Ein bloßes geöffnet haben einer Ansicht, die sich selbst regelmäßig neu lädt, genügt dabei nicht.

Verhinderung von Mehrfachanmeldungen

Die globale Option Limit login to single session at a time verhindert, dass ein Benutzer sich mit zwei Browsern parallel an Check_MK 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 zuhause aus anzumelden. Denn das Schließen des Browsers oder einfach Herunterfahren des Rechners löst keine Abmeldung aus! (Das kennen Sie evtl. von Ihrem Homebanking…).

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 durch ein beenden oder den eingestellten Timeout abwarten.

11.3. 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 omdadmin/cmkadmin verloren haben. Voraussetzung ist natürlich, dass noch eine Anmeldung als Linux-Benutzer auf dem Monitoringsystem geht und Sie mit omd su mysite Sitebenutzer werden können.

Die Passwörter sind in der Datei ~/etc/htpasswd gespeichert. In jeder Zeile stehen ein Loginname und danach ein verschlüsseltes Passwort:

~/etc/htpasswd
omdadmin:pE27XD5FleOYc
hh:$1$771269$losX.vlIY34TTR6zwiG5s1

Das Ändern geschieht mit dem Befehl htpasswd, der aus der Apache-Installation kommt. Dieser fragt Sie nicht nach dem bestehenden Passwort. Wichtig ist, dass Sie dabei als Verschlüsselung crypt() verwenden – also die Option -d:

OMD[mysite]:~$ htpasswd -d etc/htpasswd omdadmin
New password: geheim
Re-type new password: geheim
Updating password for user omdadmin

12. Eigene Benutzerattribute

Für die Alarmierung von Benutzern stehen Ihnen neben dem Feld für die Email-Adresse noch ein Feld Pager zur Verfügung. Wenn Ihnen das nicht ausreicht und Sie noch mehr Informationen zu einem Benutzer speichern möchten, können Sie mit dem Knopf Custom macros eigene Felder erzeugen, die dann pro Benutzer individuell mit Werten gefüllt werden können.

Das Anlegen eines neuen solchen Feldes bringt Sie zu folgendem Dialog:

Wie immer ist die ID später nicht änderbar, der Anzeigetitel aber schon. Das Topic legt fest, wo in der Benutzermaske 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 angezeigt werden soll.

Wichtig: Nur wenn Sie bei der Checkbox bei Make this variable available in notifications einen Haken setzen, können Sie diesen Wert auch bei Alarmierungen verwenden. Denn dazu muss der Wert dem Monitoringkern (z. B. CMC) in einer Variable (sogenanntes Custom macro) bekannt gemacht werden.

Der Name der Customvariable 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. Bitte beachten Sie, dass beim Übergeben der Variable über Umgebungsvariablen dann nochmal ein NOTIFY_ vorangestellt wird. Bei Ihrem eigenen Alarmierungsskript kommt die Variable dann also als NOTIFY_CONTACT_PHONE an.

13. Benachrichtigen von Benutzern

Im Artikel über die Alarmierung gehen wir sehr ausführlich darauf ein, wie Check_MK die Kontakte über Probleme bei Hosts oder Service informieren kann. Manchmal möchten Sie aber vielleicht alle Anwender (auch solche, die keine Kontakte sind) über Organisatorisches in eigener Sache informieren – z. B. über eine Wartung des Check_MK-Systems selbst.

Für solche Zwecke bietet Check_MK ein kleines eingebautes Benachrichtungssystem, das völlig getrennt von der Alarmierung funktioniert. Den dazu nötigen Knopf finden Sie oben in der Benutzerverwaltung. Hier haben Sie die Möglichkeit, eine Nachricht an alle (oder manche) Ihrer Benutzer zu schreiben.

Dabei haben Sie die Wahl zwischen drei Nachrichtenarten:

Send an email Versendet eine Email. Damit erreichen Sie aber nur Benutzer, bei denen auch eine Emailadresse konfiguriert ist.
Popup message in the GUI (shows up alert window) Beim nächsten Seitenaufruf des Benutzers wird ein Popupfenster mit der Nachricht geöffnet.
Send hint to message inbox (bottom of sidebar) Der Benutzer wird durch ein Zahlensymbol am unteren Ende der Seitenleiste auf die Nachricht hingewiesen und kann diese dann abrufen.

Mit der automatic invalidation können Sie noch nicht abgerufene Meldungen einfach löschen, sobald diese nicht mehr relevant sind.

14. Weiterführende Themen

Check_MK beherrscht noch einige weitere Spielarten der Anmeldung. Diese werden in einem eigenen oder in Kürze in diesem Artikel beschrieben werden:

  • Anbindung von LDAP/Active Directory
  • Authentifizierung mit Kerberos
  • Authentizierung in einem Aufbau mit Reverseproxy
  • Authentizierung mit HTTP Basic Authentication

15. Dateien und Verzeichnisse

Folgende Aufstellung zeigt Ihnen, welche Dateien und Verzeichnisse auf dem Check_MK-Server mit der Benutzerverwaltung zu tun haben. Wie immer sind alle Angaben hier relativ zum Instanzverzeichnis (/omd/sites/mysite).

Pfad Bedeutung
etc/htpasswd Passwörter der Benutzer im Apache-htpasswd-Format.
etc/auth.secret Diese Datei enthält ein zufälliges Geheimnis, mit dem Anmeldecookies signiert werden. In verteilten Umgebungen soll diese Datei in allen Instanzen gleich sein. Wenn Sie alles mit WATO einrichten, sorgt dieses automatisch dafür. 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 660 versehen, da ein Lesezugriff von Dritten das Fälschen einer Anmeldung ermöglichen würde.
etc/auth.serials 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 ausloggt.
etc/check_mk/multisite.d/wato/users.mk Enthält die über WATO eingerichteten Benutzer. Hier sind nur diejenigen Daten über den Benutzer gespeichert, die sich rein mit der GUI befassen. Manuelle Änderungen in dieser Datei werden sofort wirksam.
etc/check_mk/conf.d/wato/contacts.mk Kontaktinformationen der über WATO verwalteten Benutzer. Hier sind alle Daten abgelegt, die für die Konfiguration des Monitoringkerns relevant sind. Nur Benutzer, die auch Kontakte sind, sind hier aufgeführt. Manuelle Änderungen hier benötigen anschließend ein cmk -O (Core reload), um wirksam zu werden.
var/check_mk/web Jeder Benutzer, der sich mindestens einmal an der GUI angemeldet hat, hat hier ein Verzeichnis, in dem Dinge wie selbst erstellte Ansichten und Berichte, aktuelle Konfiguration der Seitenleiste und vieles anderes in einzelnen kleinen Dateien mit der Endung .mk gespeichert sind. Diese Dateien haben Pythonformat.
var/log/web.log Logdatei der Benutzeroberfläche. Hier finden Sie Fehlermeldungen bezüglich Authentifizierung und LDAP-Anbindung.