Cacti LDAP with Active Directory

This won’t cover all aspects of using Cacti LDAP authentication with Active Directory but I will discuss the most recent setup I performed as it was painfully annoying. In this article I’ll be using Cacti to authenticate AD users belonging to a specific domain group.

To get started, either enable the default guest account or create a new account to be used as a template for LDAP authenticated users. Once complete, set these accordingly under the “Special Users” options on the authentication settings page. For general settings, enter the IP/hostname of your AD server which will be queried. The default options such as non-SSL port 389, SSL port 636, protocol version 3, no encryption and disabled referrals should work for most people.

Moving on to the more specific settings, you need to select the search mode to match your requirement. If you simply wanted to match a user against LDAP, “No Searching” is probably fine. As I’m needing to match a user’s group membership in the domain I’ve selected “Specific Searching.” For Distinguished Name (DN) field I’m using <username>@<domain> so a real world example of that field may look like “<username>@ad.omgwtfbbq.ca.” I’ve also enabled the Require Group Membership option.

Getting down into the LDAP group settings, I’ve got my full “path” or whatever you want to call it listed under Group Distinguished Name (DN) field. A real world example may look like “CN=Cacti_Users,OU=Monitoring,OU=Groups,DC=ad,DC=omgwtfbbq,DC=ca.” I’ve got Group Member Attribute set to “member” and Group Member Type set to Distinguished Name. For the LDAP specific search settings, putting your base domain such as “DC=ad,DC=omgwtfbbq,DC=ca” should be fine or you could get more specific with group OUs. The search filter is where I ran into most of my issues, but I ended up getting it working using real world example “(&(objectCategory=user)(userPrincipalName=<username>*)(memberOf=cn=Cacti_Users,ou=Monitoring,ou=Groups,dc=ad,dc=omgwtfbbq,dc=ca)).” The * after <username> might not be required, and you may also run into problems if that search string returns more than one user. The last few fields are where you set your AD bind account which is used to perform the LDAP searching. If your mode is set to no searching or anonymous, you might not need to use a bind account. The Search Distinguished Name (DN) is the full location of the bind account in your domain, so an example would be “CN=ADBind,OU=Service_Accounts,OU=Users,DC=ad,DC=omgwtfbbq,DC=ca.” The password field would be the password for this “ADBind” domain account.

In conclusion, I hope this helps you avoid pissing away your time trying to find relevant information on Google and coming up with so many conflicting answers. Also something to note is these settings don’t appear to work with members inside of nested groups, so the search won’t return users in groups nested within the “Cacti_Users” example group mentioned in this article. Since I don’t know crap about LDAP/AD, I decided to call it a day.

Facebooktwitterredditpinterestlinkedinmail

You may also like...

1 Response

  1. SB says:

    Thanks for article. Your search query must be like this to do nested search in AD (Microsoft implementation of LDAP!)

    “(&(objectCategory=user)(userPrincipalName=*)(memberOf:1.2.840.113556.1.4.1941:=cn=Cacti_Users,ou=Monitoring,ou=Groups,dc=ad,dc=omgwtfbbq,dc=ca)).”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.