top of page

LDAPS for BigFix

Don’t Get Caught by a Relay Attack – Enable LDAPS for BigFix NOW!!

Earlier in 2020 Microsoft announced a change to the default configuration of Active Directory domain controllers that might have been disruptive to operations if not planned for appropriately. They have since changed that advisory; however, it is advisable to configure support for signed LDAP at your earliest convenience to better secure your BigFix infrastructure.

Active Directory is an implementation of the lightweight directory access protocol. Because this is a well-documented protocol many Active Directory integrations in third-party products make use of LDAP as their primary means for accessing data from Active Directory.

The primary purpose of this change is to protect your network devices from replay attacks. A replay attack is a situation where an unauthorized user captures authentication data and uses it to impersonate another user. Since Windows Server 2008 Microsoft has provided auditing data in the Windows event log under Event ID 2886 to indicate that unsigned LDAP binds are being used and that you can enhance the security of your system by requiring signed LDAP binds. A group policy setting and registry keys have existed to enable signed LDAP binds as well.

In March 2020, additional auditing information about unsigned LDAP binds was made available indicating how many binds occurred. Further information about where unsigned requests are being generated from can be enabled by setting the REG_DWORD value of HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\16 LDAP Interface Events

to “2.”

Once this logging is enabled each unsigned LDAP bind will generate a log entry under Event ID 2889 with the IP address of the computer requesting an unsigned bind and the login that was being used for the unsigned bind.

Once you’ve gathered information about what sources are generating unsigned bind requests you can then work to correct the configuration for the future. This will allow you to know which devices and applications are using unsigned binds in order to reconfigure to use signed LDAP binds. Configuring signed LDAP binds in BigFix can require changing settings in 3 places. The first change to configure signed LDAP for the BigFix root server is necessary for all BigFix installs.

Configuring LDAPS on the BigFix Root Server

LDAP directories are configured using the BigFix console. Creating an LDAPS connection is slightly different than a regular Active Directory connection. You will need to have a service account with access to the part of the Active Directory domain you wish to grab LDAP operators from. You will also need to confirm with your Active Directory administrators that the AD domain controllers are configured to accept signed LDAP binding requests and that port 636 (or whatever port you have configured for signed binds) is allowed through the Windows firewall and any access control devices that exist between your domain controllers and the BigFix Root Server.

To configure the LDAPS connection you will need to add a new LDAP directory. That is performed in the All Content domain. The LDAP Directories node is at the root of the All Content display. Navigate to it and you will something like this:

To add an LDAP directory, you will right-click in the list area and choose the only option – Add LDAP Directory. You can also add an LDAP directory by going to the Tools menu and selecting the “Add LDAP Directory.” This will present this dialog:

First, you will need to create a name for the LDAP directory. This should indicate which domain you are connecting to and any other identifiers useful in your environment. Then you will pull down the Type pulldown and select “Generic LDAP Directory.” The dialog will add additional fields like this:

For the "server" field, fill out either the fully qualified domain name of one of your domain controllers or the IP address. Unless you are running on a non-standard port leave the port field as-is. Use SSL should already be selected, and you should leave that setting as is. For the Base DN, you will need to enter the full distinguished name of the base for searching for users and groups within your directory. In many environments, it may be sufficient to enter just the distinguished name of your domain (eg. DC=bfxglobalservices,DC=com). If you are unsure of the correct entry for this field contact your Active Directory administrator to get an appropriate Base DN.

For the Login Attribute you will need to enter:


In the User DN field, you will need to enter the distinguished name for your service account. You can get this from your Active Directory administrator when they create the account. Enter the password for the account below and click on “Show Advanced Settings.” For User filter enter:


For Group filter enter:


When you are done the dialog should look as follows (obviously with appropriate values for your environment):

Click the “Test” button to test the settings. You may be asked to accept a self-signed certificate – contact your Active Directory administrators to verify what certificate the server should present. As long as it passes all the tests you can click the Add button to add that LDAP directory configuration. If you would like to configure a second domain controller for redundancy you can do so in the work area.

After you have created a new LDAP directory you will need to move your existing LDAP users over to the new directory. Do not delete users and recreate them as this will delete their user site and any content stored there.

To move a user to a new LDAP directory simply go to the Operators node and select the user you wish to move to a new LDAP directory. Right-click and select “Convert to LDAP Operator.” This will display the following dialog:

You will need to shorten the search to only the username for the LDAPS directory to show. Select the LDAPS directory version of the account and click to move the authentication to use the signed LDAP connection. You will need to perform this operation for each LDAP operator in your environment. After the accounts are using signed LDAP binds for authentication you will need to enter the username as the username alone (no domain prefix or suffix) but otherwise, the operation should be the same and all your content will be preserved. You may be asked to accept the certificate for your domain controller when you first connect to the root server if your server is using self-signed certificates.

Once you have confirmed that all the LDAP operator logins work properly, and their content is accessible you can delete the old Active Directory or LDAP configuration. Congratulations! You have now secured your BigFix Root Server from replay attacks. Some of the BigFix web applications have their own LDAP integrations. Altering those configurations will be the subject of another post.

343 views0 comments

Recent Posts

See All
bottom of page