I have setup an LDAP directory (Generic LDAP Server) for our BigFix environment and everything seemed to work within our Bigfix root servers. Now I am trying to setup the directories inside our Web Reports server and I am running into issues with it killing our domain controllers CPU. I am not sure if it is because our AD structure is so large, or maybe I have something misconfigured, but every time I click on the LDAP directory under LDAP Permissions in Web Reports it spikes the CPU of our domain controller. I have tried this against two different domain controllers and also two different BigFix environments (Prod\Test) with the same outcome. Has anyone here ever experienced this issue? As of now I have my Base DN set to dc=XX,dc=com. Is there a way i can point my query to a particular OU? All help is appreciated.
I don’t have experience with this, but I wonder if changing the Base DN would work. Maybe try having it point to the OU?
You say you are using the “Generic LDAP Server” config, but then you mention Domain Controllers and AD. I thought there was config options specific to AD instead of Generic LDAP. Not sure if this is part of the problem or not.
As usual, “It Depends”.
At one time Web Reports had its own directory service configuration, but I noticed in moving up to 9.5 that doesn’t seem to be the case anymore - new Web Reports installations pull the directory configuration from the BES Root Server (so you couldn’t have one restricted Forest for console access, and allow Web Reports logins from another, less-restrictive forest). As near as I can tell, the “LDAP Directory” must at least exist on the BES Root Server, even if there are no Operators assigned rights from that directory.
So this configuration is controlled from the LDAP Directories in the BES Root Server.
IF all of your User AND Group accounts come from somewhere further down the LDAP tree, then yes you could change the Base DN there. That’s probably unlikely though, as by default users would come from CN=Users,dc=mydomain,dc=com and Groups would come from CN=Groups, dc=mydomain, dc=com. Changing the Base DN to Users would break the Groups lookup, and changing the Base DN to Groups would change the Users lookup.
You may however be able to change the Filters to more efficiently query the servers and reduce their load. One example might be for the User Filter to only show users who are members of a specific group:
(&(objectClass=user)(objectCategory=person)(memberOf=cn=MyAllowedBESUsers,cn=Groups,dc=mycompany,dc=com))
TEST, AND USE WITH CARE. I’m not using this group membership filter for BES today. This might decrease, or might actually increase, the load on the LDAP server depending on how BES and WR are doing their lookups.
You could also change the Group Filter to only search for specific group names that you’ve tagged to use specifically in BigFix by including “-BES-” in the group name, so that we don’t retrieve every group when doing LDAP lookups (this filter is quite a bit safer than the User filter):
(&(objectCategory=group)(sAMAccountName=*-BES-*))
A combination of these might reduce the workload on your LDAP server; there may also be some further filtering if we put some more thought into it.
IBM guys, if this continues to be a problem, the biggest benefit we could get is to allow separate search bases for Users and for Groups.
I wonder if you could just configure multiple LDAP/AD servers, even if they are actually the same server, and use one config for users and another for groups.
That should also be possible by configuring multiple LDAP/AD servers, and just not use one of them for console logins and only for WebReports logins.
I’dlike to hear results if anyone tries it, but I’m not in a position to experiment myself.
I tried setting the Base DN to something like (ou=xx,dc=xx,dc=com), but never could get the query to return anything. As for the Generic LDAP Server versus the AD option. I was only speaking to where you have to set the server name in the connection configuration which we set to our DC.
Below is my current configuration in my lab and everything works perfectly for Bigfix root server authentication. But when trying to use the connection to add users into our Web Reports site it pegs the CPU on our DC as soon as I click on connection link under LDAP Permissions. If I wait for about 10 minutes the CPU issue resides on the DC and I can then select the users I want to add to Web Reports. It seems that narrowing down the query results might fix my issue, but I am not sure how to do that.
Did this work eventually? What did I solve?
This did work, I had tried this in the previous weeks but kept receiving a connection error when testing. Evidentially I had gotten the syntax wrong multiple times, because I tried this approach again this week and everything worked as should. Man what a fresh set of eyes will do. Thanks again for your help.