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

There are some limitations with Contacts that use LDAP for authentication:

• They cannot logon to the Nagios® Core CGIs on slaves - this is because the slaves do not necessarily have LDAP connection

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

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

The file needs to look like the following for ActiveDirectory:

---
authentication:
  realms:
    ldap:
      credential:
        class: Password
        password_field: password
        password_type: self_check
      store:
        class: LDAP
        ldap_server: ldap.company.com
        ldap_server_options:
          timeout: 30
        binddn: anonymous
        bindpw: secret
# Use bindpw_encrypted instead of bindpw if you want an encrypted value. Use the 'opsview_crypt' tool to generate the value
#        bindpw_encrypted: 88ff95374e563866f6c3c2af4517979a3dc14ea3cbdadb8684ada121e210e818
        start_tls: 0
        user_basedn: cn=Users,dc=ldap,dc=company,dc=com
        user_filter: (sAMAccountName=%s)
        user_scope: one
        user_field: samaccountname
        user_search_options:
          deref: always
        use_roles: 0
        opsview_sync:
          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

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:

---
authentication:
  realms:
    ldap:
      credential:
        class: Password
        password_field: password
        password_type: self_check
      store:
        class: LDAP
        ldap_server: localhost
        ldap_server_options:
          timeout: 30
        binddn: anonymous
        bindpw: secret
# Use bindpw_encrypted instead of bindpw if you want an encrypted value. Use the 'opsview_crypt' tool to generate the value
#        bindpw_encrypted: 88ff95374e563866f6c3c2af4517979a3dc14ea3cbdadb8684ada121e210e818
        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
        user_search_options:
          deref: always
        use_roles: 0
        opsview_sync:
          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.

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

ldap_server: ldap.company.com

ldap_server: 
- ldap.company.com
- backup-ldap.company.com

ldap_server_options:
  timeout: 30

ldap_server_options:
  timeout: 30
  scheme: ldaps
  capath: /path/to/ssl/certs
  verify: require

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.

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

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:

<contact>
<name>%NAME%</name>
<username>%SAMACCOUNTNAME%</username>
<comment>%USERPRINCIPALNAME%</comment>
<role><name>View some, change none</name></role>
<variables><name>EMAIL</name><value>%USERPRINCIPALNAME%</value></variables>
<variables><name>RSS_MAXIMUM_ITEMS</name><value>100</value></variables>
<variables><name>RSS_MAXIMUM_AGE</name><value>2880</value></variables>
<variables><name>RSS_COLLAPSED</name><value>1</value></variables>
<variables><name>PAGER</name><value>%telephonenumber%</value></variables>
<all_hostgroups>0</all_hostgroups>
<hostgroups>
 <hostgroup name="Windows" />
 <hostgroup name="Solaris" />
</hostgroups>
<all_servicegroups>0</all_servicegroups>
<servicegroups>
 <servicegroup name="Operations" />
</servicegroups>
<keywords>
 <keyword name="publicwebsite"/>
</keywords>
</contact>

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.

Example 2 - READ ONLY yourldapgroup.xml

<contact>
<name>%NAME%</name>
<username>%SAMACCOUNTNAME%</username>
<comment>%USERPRINCIPALNAME%</comment>
<role><name>View all, change none</name></role>
<variables><name>EMAIL</name><value>%USERPRINCIPALNAME%</value></variables>
<variables><name>RSS_MAXIMUM_ITEMS</name><value>100</value></variables>
<variables><name>RSS_MAXIMUM_AGE</name><value>2880</value></variables>
<variables><name>RSS_COLLAPSED</name><value>1</value></variables>
</contact>

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.

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:

• http://jxplorer.org/
• http://ldaptool.sourceforge.net/

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.

Finally To add all contacts into Opsview run

/usr/local/nagios/bin/opsview_sync_ldap -y

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.

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.

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.

If it takes takes multiple times to sign in to the Web interface, check to see if you have multiple domain controllers and they are all reachable via the Opsview master server.