Welcome to docs.opsview.com

Authentication and Authorisation via LDAP

If you want to authenticate users in Opsview from LDAP or Active Directory, there are two parts to it:

  • Users can authenticate to Opsview using their LDAP credentials
  • Optionally, you can run a synchronisation script to create users in Opsview based on LDAP group membership. This also controls authorisation

Logging into Opsview using LDAP credentials

The process is:

  • Setup an LDAP realm for the Opsview web application
  • For users associated to that realm, their credentials will be passed to LDAP for verification

Setting up an LDAP realm

You need to add configuration into /usr/local/opsview-web/opsview_web_local.yml.

Do not change opsview_web.yml as this file is changed during an upgrade

The file needs to look like the following for ActiveDirectory:

        class: Password
        password_field: password
        password_type: self_check
        class: LDAP
        ldap_server: ldap.company.com
          timeout: 30
        binddn: anonymous
        bindpw: secret
        start_tls: 0
        user_basedn: cn=Users,dc=ldap,dc=company,dc=com
        user_filter: (sAMAccountName=%s)
        user_scope: one
        user_field: samaccountname
          deref: always
        use_roles: 0
          group_dir: /usr/local/nagios/etc/ldap
          group_basedn: cn=Users,dc=ldap,dc=company,dc=com
          group_filter: (&(objectClass=group)(sAMAccountName=%s))
          group_scope: one

Note: The user_field must be samaccountname in lowercase. If you set the user_field to sAMAccountName, you could get this error:

Deep recursion on subroutine "Catalyst::Authentication::Store::LDAP::User::stringify" at /usr/local/nagios/perl/lib/Catalyst/Authentication/Store/LDAP/User.pm line 290, <DATA> line 466.

Or like this for OpenLDAP:

        class: Password
        password_field: password
        password_type: self_check
        class: LDAP
        ldap_server: localhost
          timeout: 30
        binddn: anonymous
        bindpw: secret
        start_tls: 0
        user_basedn: ou=People,dc=ldap,dc=company,dc=com
        user_filter: (&(objectClass=posixAccount)(objectClass=inetOrgPerson)(uid=%s))
        user_scope: sub
        user_field: uid
          deref: always
        use_roles: 0
          group_dir: /usr/local/nagios/etc/ldap
          group_member_field: memberUid
          group_basedn: ou=Group,dc=ldap,dc=company,dc=com
          group_filter: (&(objectClass=posixGroup)(cn=%s))
          group_scope: sub

If you are not using the synchronisation script below, you still need to create users in LDAP and assign them roles.

Make sure the file is created with readable permissions for the nagios user.

This file is yml based, so is very particular about whitespace. Do not use tabs - it must be spaces to separate the file.

This realm will be added in addition to the “local” realm defined in /usr/local/opsview-web/opsview_web.yml.

Note: Depending on your LDAP configuration, your basedn and user_field may vary. Also, the basedn maybe ou rather than cn depending on your LDAP tree.

Note: The user_scope or group_scope defines how far down in the LDAP tree to search. A setting of one means only search down one level. A setting of sub means to search all levels below. You may need to set to sub to find the appropriate entries.

Note: The LDAP server needs to have a system user defined that can query specific basedns. The authentication works by initially binding to LDAP with the binddn user, searching for an appropriate user based on the user_field attribute, then rebinding to LDAP with that user and the given password. In the above example, the binddn user is anonymous with a password of secret, though this could be changed. The binddn user needs enough permissions to search for other users, and to search for group memberships. This is a limitation of the way the Catalyst modules interact with the LDAP server.

To define multiple LDAP servers the 'ldap_server:' entry should be changed from

ldap_server: ldap.company.com


- ldap.company.com
- backup-ldap.company.com

Ensure you keep the indentation correct.

When configured, you can run /usr/local/nagios/bin/opsview_sync_ldap -t to test the connection with your LDAP server.

To make the realm available in the web UI, restart Opsview Web: /etc/init.d/opsview-web restart.

Possible errors:

  • Error on initial bind: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece - binddn and bindpw are incorrect


When there is more than 1 realm defined, there is an extra drop down in the contacts edit page to select which realm. The user is then authenticated via that particular realm in future.

Synchronisation script

/usr/local/nagios/bin/opsview_sync_ldap is a script to run nightly as the nagios user to make changes to the list of contacts based on the LDAP directory - including which role they have for authorisation purposes. It goes through the following steps:

  • Parse LDAP connect information from opsview_web.yml and opsview_web_local.yml
  • Connect to LDAP with the specified binddn and bindpassword
  • Read each group file from the specified directory
  • For each group, get a list of users in that group. Find those users and expand the group XML file based on attributes for that user
  • If specified at command line, commit changes and remove users that do not belong in any of the groups
  • If a change has been made, initiate an Opsview reload

This will create users and set their contact information based on the XML data. If the user already exists (based on the username), then their details will be updated.

Warning: If you have manually added contacts into Opsview for the ldap realm and then wish to use the sync script, run it without the -y option (to ignore making changes), because it could remove existing contacts if your group permissions in LDAP have not been setup correctly.

Default group attributes

The opsview_sync_ldap script expects to find the group definition files in /usr/local/nagios/etc/ldap by default. Each file in this directory is a group name, as defined in LDAP. Each file is in an XML format to hold the initial create information.

For example, you could have a file called opsview-admin (you can also suffix with .xml if you wish) with the contents of:

<role><name>View some, change none</name></role>
 <hostgroup name="Windows" />
 <hostgroup name="Solaris" />
 <servicegroup name="Operations" />
 <keyword name="publicwebsite"/>

The list of roles you can pass are listed in the access page.

Note that you can use macros, which are of the format %MACRONAME%. The macro name will be expanded out with the LDAP attributes returned. You can run opsview_sync_ldap -a to list all the attributes returned from LDAP.

Any fields that are not defined in the XML will be inserted with default values.

If a user belongs to more than one group, then a warning will be displayed. The user will be created with the first group information it matches against. In LDAP, the users should not belong to two different groups.

Login errors

If you get the error message “Authentication error: contact administrator” on the login page, check the audit log entries as this will show the specific authentication failure. These are usually exceptional failures, such as ldap server unavailable, or unable to bind with the initial bind user. The error will also be seen in the /var/log/opsview-web.log.


Seeing your LDAP structure

If you need to navigate your LDAP directory and see the structure, LDAP browser is commercial software that provides this functionality. You can purchase from http://www.openchannelsoftware.com/projects/LDAP_Browser_Editor.

Alternatives are:

Testing LDAP connectivity

Use opsview_sync_ldap with -t to test connectivity to LDAP, using the configured bind credentials:

/usr/local/nagios/bin/opsview_sync_ldap -t

You can also enter a username and password to see if the username credentials would work correctly.

/usr/local/nagios/bin/opsview_sync_ldap -t -u {username} -p {password}

This uses the same routines that Opsview would use, so if it works here then authentication via Opsview should work too.

Remember, if you make changes to opsview_web_local.yml, you must restart opsview-web for the effects to be available from the web front end.

opsview-web will not restart

If you get the error:

Cannot find version string in opsview_web.yml - file is possibly invalid (remove any hard tabs)

Then you have probably got tabs in the opsview_web_local.yml file. YML requires spaces only - remove tabs from the configuration file.

XML invalid

If you get something like:

End tag mismatch (contact != notification_period) [Ln: 21, Col: 9]

Then your XML is likely to be bad. Check that the XML is valid.

Hostgroup/Servicegroup names incorrect

If you get something like:

DBIx::Class::Row::insert(): DBI Exception: DBD::mysql::st execute failed: Column 'hostgroupid' cannot be null [for Statement "INSERT INTO hostgroupnotify (contactid, hostgroupid) VALUES (?, ?)" with ParamValues: 1=undef, 0='3'] at /usr/local/nagios/bin/opsview_sync_ldap line 211

Then the hostgroup you have specified in the XML does not exist.