Users, roles and permissions


1. Introduction

In this article we will present information on all aspects of user management and permissions in Check_MK. Before we go into the details, however, we'll first need to explain a few terms.

In Check_MK a user is one with access to the User interface. They have one or more Roles. From these roles Permissions are derived.

Once a user is made responsible for specific hosts and services, they are identified as a Contact. A contact normally sees only their own hosts and services in the user interface, and receives notifications regarding possible problems.

There are also users who are not contacts. An example would be omdadmin, (cmkadmin starting at 1.4.0) which is generated automatically when an instance is created. This can in fact see all hosts and services, but only because its admin role includes the See all hosts and services permission - not because it is a contact for all.

If a contact has only been created for the purpose of notifications (e.g. for forwarding notifications to a ticket system), it can be sensible to set it up so that a login is not possible in the interface.

A Contact is always a member of one or more Contact Groups. The purpose of these groups is the allocation of contacts to hosts and services. For example: the contact hhirsch could be in the linux contact group, and this can in turn be allocated to all Linux hosts via rules. A direct allocation of contacts to hosts or services is not possible, and in practice would create difficulties (e.g., when 'retiring' a user).

To summarise:

  • Users can utilise the user interface.
  • Contacts are users who are responsible for specific hosts and services.
  • Contact Groups define what someone is responsible for.
  • Roles define a user's Privileges.

2. User management with WATO

User management can be found in the Users WATO module . In a newly-created instance this page will appear as below:

Here omdadmin/cmkadmin can be seen - the only user which is automatically generated when a new instance is created. In Check_MK-Appliance this user can have a different name because you can specify the name and password yourself.

This first user has the following characteristics:

  • It has the Administrator (admin) role and therefore has all permissions!
  • It is a contact for nothing and receives no notifications.
  • It can however view everything (due to its admin role).
  • The default password should be replaced by a new one as soon as possible!

Incidentally, on the Users page title line you can always see your logon-ID and (role):

The mask for creating a new user with , or for editing an existing user with consists of four sections.

The first subsection menu is for the identity:

Identity

As always in Check_MK, the ID of a dataset - (here Username) - cannot be changed retrospectively. This will be used for the registration and also as an internal key in all files and file structures.

The email address is optional and only required if the user is to be a contact who should receive notifications by email. The Pager address field is analogous and is intended for notifications per SMS or similar systems. If you are coding your own notification scripts, the values in these fields can be accessed and used as required.

Security

The second subsection menu is for the login and permissions. The Automation secret for machine accounts option is intended for accounts that are controlled by scripts, which access Check_MK per HTTP, and which are authenticated via the URL. Later we will show how this works see below.

At least one role must be selected. You can theoretically give multiple roles to a user - in which case ithe user will receive the authorisations from all of these roles. With the three predefined roles (see below) this would make little sense however.

If you lock a user with the disable the login to this account option, it will appear with the symbol in the table. It will not be able to login but will nonetheless remain in the system. If it is a contact its notifications will not be affected and it will still receive emails, etc. If the user was logged in at the time of the locking action, it will be automatically logged out.

Contact groups

As soon as a user is allocated to one or more contact groups it will become a contact. For a new instance the contact group Everything is automatically generated, which will always include all hosts and all services (In earlier system versions this group was called Everbody, but the name was thought to be misleading). A user in this group is automatically responsible for all hosts and services.

Personal settings

All settings in the last subsection menu can also be changed by the user themselves using - (except when in the guest role). Apart from the choice of language, the interface contains some rarely-required settings - as always details for these can be found in the online help .

3. Contact groups

3.1. Creating and editing contact groups

Contact groups are the link between hosts and services on one side and contacts on the other. Every contact group represents a responsibility for a specific area in your IT landscape. For example, the SAP contact group could include all personnel who manage a SAP system, and the group allocated to all hosts and services providing service to this area.

Contact groups are administered with the Contact groups WATO module. The following screenshot shows this module with four defined contact groups:

The creation of a new group is a simple matter. As always, the ID is fixed, and the alias is a display name that can be changed at any later time:

The new contact group is at first empty in two respects: it contains neither contacts nor hosts and services. The allocation of contact groups to contacts is achieved with the user profile, as we have already seen in user editing. The allocation of hosts and services is performed as follows:

3.2. Allocating hosts to a contact group

There are two methods for adding hosts to contact groups: via Folder and via Rules. Both methods can also be used in combination. In this case the host is allocated the sum of the respective contact groups.

Allocation via folders

The attributes of a folder are accessed using the button when in the folder. Here you will find the Permissions option. Activate this check box to access the contact group selection:

The actual purpose of this option is to set permissions for administering hosts in WATO - which will be covered in detail below. When assigning permissions for specific contact groups, at the same time you can enter these as contact groups for the hosts in monitoring. You can also decide whether these should be applicable to hosts in subfolders, and if the host's services should also explicitly receive these groups. Services without an explicit allocation in fact inherit all of a host's groups, including those allocated via rules.

Attention: The Inheritance of these Permissions-Attributes via the folder is overridden by this procedure. This allows you to allocate other contact groups to subfolders. The allocations are thus cumulative through all parent folders if in these the Add these groups as contacts in all subfolders option is active.

Incidentally, the contact group options may also be found in a simplified form directly in a host's details. Hence there you can also allocate contact groups to individual hosts. As this can quickly become complex however, it should only be used in exceptional cases, and if really necessary it would probably be preferable to work with rules.

Allocation via rules

The second method - allocating contact groups via rules - is somewhat more involved, but is considerably more flexible however. It is also very useful if your folder structure has not been built following an organised plan, so there is therefore no clear way to simply allocate the folders to contact groups.

The rule set required for this - Assignment of hosts to contact groups - can be accessed quickly via the contact group's WATO module and using the button. In this rule set you will find a predefined rule - Everything - which is generated when an instance is created, and which assigns all of the hosts to the contact group.

Please note that this rule set is defined so that all relevant rules will be evaluated, and not just the first one! It can in fact be useful to have a host belonging to multiple contact groups, and in such a cases each assignment will require its own rule.

3.3. Assigning services to contact groups

It is not always a matter of course to have a service in the same contact group as its host. Therefore, using the Assignment of services to contact groups rule set you can assign services to contact groups - independently of the host's groups. The following rules apply:

  • If no contact group is assigned to a service, it will automatically receive the same contact groups as its host.
  • When at least one contact group is explicitly assigned to a service, the service will no longer inherit its host's contact groups.

In a simple environment it is sufficient to just allocate contact groups to the hosts. Once more differentiation is required rules for the services can also be defined.

Controlling the allocation

In details for a host or service, located in the Status Overview, you can verify whether all rules and folders have been correctly configured. Here you can find the Contact groups and Contacts entries which list the allocation in effect for the object.

4. Visibility of hosts and services

The fact that a normal user - (the 'user' role) - only sees the objects for which they are a contact becomes more important as monitoring environments get larger. This not only simplifies the overview, but also precludes users from interfering where they have no business being.

As the administrator - (the 'admin' role) - you can of course see everything. This is controlled by the See all host and services permission. In your personal settings you will find the Only show hosts and services the user is a contact for check box. With this you can optionally give up the 'See all' permission and thereafter see only the hosts and services for which you are a contact. This option is intended for dual roles - for someone who is simultaneously both the administrator and a normal user of the monitoring.

The 'guest' role is predefined so that your users can also see everything. An intervention or personal settings are deactivated here.

For normal users the visibility in the complete status overview is constructed so that in the system it appears as if those hosts and services for which one is not a contact simply do not exist.

Among others, the following elements influence the visibility:

Visibility of services

As we showed earlier it is possible that one can be a contact for a host, but not for all of its services. You will nonetheless be able to see all of the host's services in the GUI.

This exception is predefined in this way because it is generally so useful. In practice, for example, this means that the colleague who is responsible for the host itself can also see such services (hardware, operating systems, etc.) that actually have nothing to do with the host. They will receive no notifications from these however!

If you don't like this you can change it. The global option for this is Monitoring Core ➳ Authorization settings. If here you change Hosts to Strict - Must be explicit contact of a service users will only be able to see services if they are directly assigned as contacts for the service.

All of this actually has nothing to do with a service inheriting its host's contact groups in the case of it not having any of its own defined. You would then be a contact for the service (and receive its notifications).

Host and service groups

The second setting in this option concerns host and service groups. You can normally always see a group if you can see at least one of the group's elements - the group will however appear to contain only those elements that are visible to you.

Switching to Strict - must be contact of all members hides all groups for which you are not a contact for at least one host or service in the group.

Please note that both of these settings for visibility have no influence on notifications.

5. Notifications

Contact assignments also have an influence on notifications. By default Check_MK notifies all contacts of an affected host or service when problems occur. This is handled by a notifications rule which is automatically created for a new instance. This is a very sensible procedure.

Nonetheless, you can customise the rule or supplement it with additional rules if desired, so that a notification can be triggered in an extreme case - or even quite independently of contact groups. A common situation is when there are specific notifications that a user does not want to receive, or vice versa, a user wishes to be informed of problems with certain hosts or services even if they are not responsible for those services (and consequently is not a contact).

Details can be found in the Article on notifications.

6. Roles and permissions

6.1. Predefined roles

Check_MK always assigns permissions to users using rules - never directly. A role is nothing more than a list of permissions. It is important to understand that roles define the level of permissions and not an actual connection to any hosts or services. Contact groups exist for this purpose.

Check_MK is provided with the following three predefined roles - which are never deleted, but which may be customised as required:

Role Permissions Function
admin All permissions - notably the authority to change permissions. The Check_MK Administrator, responsible for managing the monitoring system itself.
user May only view its own hosts and services, may only make changes to shared folders in WATO for which it has been authorised, and in general is not permitted to do anything that affects other users. The normal Check_MK monitoring user who reacts to notifications.
guest May see everything but change nothing. Intended 'just for looking' - in doing so all guests share a common account. Also useful for public status screens that hang on a wall.

Roles are managed in the WATO Roles & Permissions module:

Incidentally - when a new Check_MK instance is created only a single user with the admin role will be generated (omdadmin/cmkadmin). The other two roles will not be used initially. Should you require a guest user you will have to create it yourself.

6.2. Adapting existing rules

As usual, the editing mode for a rule is accessed via the symbol:

The functions of the numerous permissions can be found in the online help.

What's special here - for every permission there are three possible selections: yes, no and default (yes) or respectively default(no). Initially, all values are set to default. For the permissions themselves at first it makes no difference whether you set them to yes or default (yes). A new version of Check_MK can alter these default values however (this occurs very rarely). Explicitly made settings will not be affected by such a change.

Additionally, with this principle you can very quickly identify where a Check_MK varies from standard.

6.3. Defining your own roles

It might come as a surprise that there is no button for creating a new role. There is a purpose behind this! New roles are derived from existing roles using the Clone button. The new role is not simply a copy, but retains a connection to the source role (Based on role):

This connection has an important function, one with which all of the cloned role's permissions that have not been explicitly set (remain set to default) will be inherited from the original role. Subsequent changes to the source role will then be passed on. This is very practical when one considers how many permissions are available. With simple copies it would be easy to lose the overview - which is what actually makes your self-defined roles so special.

This derivation solves another problem: since we are actively developing Check_MK new permissions are added from time to time. At these times we decide in which of the three roles - admin, user and guest - the new permission should be included. Because your own roles have been derived from one of these three, the new permission will be automatically preset to a sensible value. It would be simply very impractical, for example, if you defined your own user role in which new permissions were always missing. You would then be in the situation where for every new feature your role would have to be adapted in order for your users to be able to use it.

6.4. Comparing roles with the matrix view

The button helps if you wish to compare the permissions in the individual roles. This generates the display below, in which not only the individual roles' permissions can be compared, but in which you can also see the positions in which explicit permissions have been activated, (Symbol ), or respectively, deactivated (Symbol ).

7. Personal settings

A small part of the user settings can be self-managed by every user. This is found at the foot of the side bar at the button. This opens the below menu:

The most important function here is changing the password. The user must enter both the existing and the new password. As always, a description of the other setting options can be found in the online help.

In a distributed monitoring, following each change the new settings will be immediately passed on to all monitoring instances. Only in this way can it be ensured that the new password will immediately function everywhere - meaning it will not be dependent on the next activation of changes. This however only works for sites that are accessible to the network at this point of time. All other sites will receive the updates with their next successful Activate changes.

8. Automation user (for Webservices)

When connecting Check_MK to other systems it is often desired that specific tasks normally performed using the GUI be automated. Some examples of these are:

  • Setting and removing downtimes with script
  • Managing hosts in WATO with Web-API
  • Retrieving data from views as CSV or JSON files for further processing
  • Retrieving the current status of BI-Aggregates, in order to create services from them

In this situation an external software must be able to open specific Check_MK-Overview URLs automatically. And naturally, here the question is how the user login is to be performed. The usual method using the login mask is cumbersome, requiring the opening of a number of URLs in sequence and the saving of a cookie.

To simplify this procedure Check_MK offers the concept of the Automation user. These users are intended exclusively for remote control and don't permit normal GUI logins. Authorisation is achieved using specific variables in the URL.

An automation user is created like a normal user, but instead of a password it receives an Automation secret - which can be generated automatically with the randomising die:

Just like a normal user, an automation user has a role and can also be a contact. With these you can thus restrict its permissions and visibility of hosts and services as required.

When opening websites automatically, you enter the following additional variables in the URL:

_usernamethe automation user's ID
_secretthe user's Automation secret

Here is an example for opening a view in the JSON-Format with the automation user automation and the secret as in the above image:

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%"
 ],
 ...

If the script that opens the URL is running directly in the monitoring instance you can read the user's secret directly from the data system. This is not a security flaw, rather it is specifically intended to be so. With this the automation script can be written without containing the secret and also without requiring configurations data. To this end, simply select the file: ~/var/check_mk/web/myuser/automation.secret:

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

In the shell you can easily save this file's content in a variable:

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

This also, for example, makes use of the downtime script, which can be found in the Check_MK Treasures and with which script-controlled planned downtimes for hosts and services can be specified and deleted. If the automation user is called automation as shown in our example, only a single argument needs to be entered - the hostname for which the downtime is to be defined:

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

You can learn about further options for this script in this online help:

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

9. Automatic login via the URL

As we have seen, with automation users, using script control you can open URLs arbitrarily without logging in. In situations requiring a real browser this does not function, as the login data for contained links (e.g., images and iFrames) will not be forwarded.

The best example for this is the desire to hang a screen which continuously displays a particular Check_MK dashboard on a wall. The screen should be controlled by a computer that on starting automatically opens the browser, logs itself in to Check_MK, and calls up the dashboard.

In order to realise this, the best method is to first create a special user. The guest role is well-suited here because it has all read permissions but no authority for accesses or to make changes.

The URL for an automatic login is constructed as follows:

  1. Begin with http://mycmkserver/mysite/login.py?_origtarget=
  2. Determine the the actual URL to be displayed (e.g., that of the dashboard) with your browser - ideally so that only the right-most frame is displayed, without the side bar.
  3. Add this URL, leaving out out everything before /mysite/...
  4. Append both variables into the URL - _username and _password - in the following format: &_username=myuser&_password=mysecret
  5. Add a &_login=1

Here is an example of such a URL:

http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1'

Please note:

  • Substitute your own values for the mycmkserver, mysite, myuser and mypassword fields in the example.
  • If the special characters & or % are present in these values, or in the value for the _origtarget field, they must be substituted as follows: & by %26 and % by %25.

Test this by logging out of Check_MK in your browser, and then pasting the contructed URL in the browser's address field. You should then arrive directly in the target site - without a login screen. You will simultaneously be logged in though, and be able to open the page's included links.

You can also try the finished URL with curl on the command line. If you have done everything correctly you will receive the result “302 Found” and a (“The document has moved...”) redirection.

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>

If an error occurs you will receive the login mask's HTML code - this ends with the following code:

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

10. WATO permissions

10.1. Importance of the user role for WATO

If you have a somewhat larger monitoring environment to manage, then you will certainly want to involve colleagues in the the configuration, and especially in the managing of hosts and services. So that you maintain control over who can control what - and in so doing not get in their way - you can allocate permissions based on folders in WATO.

The first step is for your admin-colleagues to work with their own user-IDs based on the user role. In principle this role has a permission for WATO, with a couple of important restrictions however:

  • Only changes to hosts, services, rules and BI-Aggregates are allowed.
  • Hosts, services and rules may only be managed in authorised folders.
  • BI-Aggregates may only be managed in authorised BI-Packages.
  • No action with a global impact is permiited.

If you haven't yet shared folders or BI-Packages, members of the user role can make no changes at all! The side bar's WATO-element looks like this for normal operators:

10.2. Enabling users to manage hosts

The permission for a user to create, edit and delete hosts is given via Contact groups. The procedure is as follows:

  1. Add the user to a contact group.
  2. Specify one or more folders for which the user should be authorised.
  3. Activate the Permissions attribute for this folder and there select the contact group.

The following example shows the attributes of a folder in which all of the Linux contact group's users are permitted to manage hosts. Here the option to permit actions in subfolders is also activated.

Whether you wish to add the hosts to the contact groups automatically is up to you. In this example the Add these groups as contacts to all hosts in this folder option has not been selected, and the hosts will thus not be added to the Linux contact group. They will therefore not be visible in the status overview for this Linux contact group (as long as this is not handled by a rule). As can be seen, the visibility (and the responsibility in monitoring) and the permission are thus separately controllable for WATO.

11. Changing a password, password policies

11.1. Password security

Security has a high profile nowadays. Therefore in some organisations there are generally guidelines for working with passwords. Check_MK offers a number of approaches for enforcing such guidelines. One of these can be found in the global settings under User management ➳ Password policy for local accounts:

The first two settings should secure the password quality. There are altogether four character groups (types) for the second setting:

  • Lower case letters
  • Upper case (capital) letters
  • Numerics
  • Special characters

Enter a 4 here, so that a password must contain at least one character from each of the above-named groups. With a 2 it will at least be ensured, for example, that a password doesn't consist only of lower case letters. These settings will be verified with every password change.

The third setting will force the user to change their password at regular intervals. As soon as this time period has expired the next attempt to access a page will direct the user to the following entry mask:

Only after changing their password will the user be permitted to continue. You can stipulate a change from the initial (administrator-provided) password immediately at the user's first login. The Enforce change: Change password at next login or access option in the Security section serves this purpose.

11.2. Login policies

Suspension following login failures

Further settings applicable to user logins can be found under User management in the global settings. With the Lock user accounts after N logon failures you can lock a user's account following a predetermined number of login failures:

Unlocking can only be performed by a user with the admin role. Please note however, that the administrator account itself can also be locked! Should you be conclusively locked out, you can unlock your account via the command line. As the instance user, also edit the etc/htpasswd file by removing the exclamation mark from the affected user's line.

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

Following this procedure you will be able to log in again.

Automatic logout

A further setting ensures that a user whose GUI has been idle for long time will be automatically logged out:

The timeout will be held up only by active use of the GUI. An open view that just refreshes itself regularly doesn't satisfy this criterion.

Prevention of duplicate logins

The global Limit login to single session at a time option prevents a user logging in to Check_MK from two browsers in parallel. This option is at the same time linked with the timeout for automatically logging off idle users. This also makes sense. Assume you have forgotten to log yourself out before closing the browser at your workplace. In such a situation, without a timeout it would not be possible for you to log in from home if you were on call - because closing the browser or simply shutting down your computer doesn't execute a logout! (You may be familiar with this from your homebanking...)

An attempt to log in a second time in parallel receives the following notice:

In this situation a log in can only be completed if you first end the active session with , or wait for it to time out after the specified idle time.

11.3. Changing a password using the command line

In an extreme case a password can be changed via the command line. This rescues you if the omdadmin password has been lost. It will naturally depend on your being able to log in as a Linux user to the monitoring system and that you can become a site user with omd su mysite.

The passwords are stored in the ~/etc/htpasswd file. Each line contains a login name followed by an encrypted password:

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

The password change is performed using the htpasswd command that comes from th Apache installation. This does not ask for the existing password. It is important that you use crypt() as the encryption - thus the -d option:

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

12. Own user attributes

For user notifications, alongside the field for the email address there is a Pager field available. If that is not sufficient for your needs and you want to store more information to a user, with the Custom macros button you can create your own fields in which values for each user can be individually entered.

Creating such a new field opens the following dialogue:

As always, the ID cannot subsequently be changed, but the display name can be changed at a later date if required. Topic specifies to where the new field should be sorted in the user mask. Furthermore, you can decide whether the field's users will be permitted to edit the field themselves (it will then appear in their personal settings), and whether the value should be directly displayed in the user table.

Important: Only if the check box in Make this variable available in notifications has been selected can this value also be used in notifications. Additionally this value (e.g., CMC) must be made known to the monitoring core in a variable (a so-called custom macro).

The custom variable's name will be derived from that of the selected ID. This name will be converted to upper case letters and a preceeding 'CONTACT_' will be added. Thus from 'phone' the 'CONTACT_PHONE' custom variable will be generated. Please note that when passing this value over environment variables a 'NOTIFY_' will additionally be appended. For your own notification script the resulting variable will be 'NOTIFY_CONTACT_PHONE'.

13. Notifying users

In the article on notifications we very comprehensively cover how Check_MK can inform contacts of problems with hosts and services. You may also occasionally wish to inform all users (even those who are not contacts) about organisational matters that are in their interest - for example, about maintenance affecting the actual Check_MK-System.

To this end Check_MK offers a small built-in messaging system that functions quite independently of the monitoring's notifications. The button required for this purpose is located at the top of the user management. With this you have the facility to compose a message to all (or some) of your users.

Here you can choose from three types of message:

Send an email With this you will only reach users for whom an email address has been configured.
Popup message in the GUI (shows up alert window) A popup window containing the message will open in the overview with the user's next page request.
Send hint to message inbox (bottom of sidebar) The user will receive a numeral at the bottom of the side bar advising that a message is in their inbox - which the user can then open at will.

With automatic invalidation not yet opened messages can simply be deleted once they are no longer relevant.

14. Further topics

Check_MK commands a number of additional variations for logging in. These will be briefly discussed in this or an own article:

  • Connection from the LDAP/Active Directory.
  • Authentification with Kerberos
  • Authentification in a construction using Reverseproxy
  • Authentification with HTTP Basic Authentication

15. Files and directories

The following summary shows which files and directories on the Check_MK-Server are associated with user management. As always all information here is relative to the instance's directory.

File path Function
etc/htpasswd User passwords in Apache-htpasswd-Format.
etc/auth.secret This file contains a random secret for signing login cookies. The file should be the same in all instances in distributed environments. When you configure everything with WATO it will take care of this file automatically. If this data is changed all logins will immediately be void and users must log themselves in anew. The file is furnished with the 660 permission, as read access could enable a third party to falsify a login.
etc/auth.serials The serial numbers of the passwords by user. Every password change increments the serial number, thereby making all current sessions invalid. This ensures that a password alteration reliably forces a user to log out.
etc/check_mk/multisite.d/wato/users.mk Contains the users that have been defined using WATO. Here only the user data directly concerning the GUI is stored. Manual changes to these files will take effect immediately.
etc/check_mk/conf.d/wato/contacts.mk Contact information for users managed using WATO. Here all data relevant for the monitoring core's configuration are stored. Only users who are also contacts are listed. Changes made manually here will subsequently require a cmk -O (Core reload) to be effective.
var/check_mk/web Every user who has signed in to the GUI at least once will have a directory here in which items such as self-created views and reports, their current side bar configuration, and many others, will be stored in small files with the .mk file extension. These files have the Python format.
var/log/web.log The user interface's log data. Here error messages relating to permissions and LDAP connections can be found.