How to troubleshoot problems with LDAP Broker

In this topic, you will learn how to troubleshoot typical problems with the operation of the Portnox™ Active Directory Broker.

Error Reason Solutions
The Portnox Cloud portal does not list the broker
  1. The broker never sent any data
  2. The broker hasn’t sent any data for more than 30 minutes
  3. The broker directory cluster was deleted
  1. Verify that the broker is installed
  2. Verify that the broker service is running: Where to find the LDAP Broker service
  3. Check if the cloud servers are reachable from the broker: How to check if the LDAP Broker connects to the cloud
  4. Reinstall the broker to configure it again (in case the broker directory cluster was deleted)
  5. Check the broker logs: Where to find the LDAP Broker logs and status
Broker status: Dormant The broker hasn’t sent any data or logs to the cloud for more than 30 minutes
  1. Verify that the broker service is running: Where to find the LDAP Broker service
  2. Check if the cloud servers are reachable from the broker: How to check if the LDAP Broker connects to the cloud
  3. Check the broker logs: Where to find the LDAP Broker logs and status
Broker status: Not operational There are issues with the access to the directory cluster.
  1. Check the directory cluster settings in Portnox Cloud: Settings > Authentication Repositories > DIRECTORY INTEGRATION SERVICE > Directory domains
  2. Check if the local LDAP server is reachable from the broker: How to check if the LDAP Broker connects to the LDAP server
  3. Check the broker logs: Where to find the LDAP Broker logs and status
  4. If you changed the credentials of the service account used to run the broker, follow this guide to update the credentials in the broker configuration: How to update LDAP Broker configuration after credential change.
Broker status: Wrong LDAP credentials The LDAP credentials are missing or wrong. This might happen if someone changed the admin credentials on the LDAP server, or if someone changed the LDAP server address in Portnox Cloud.
  1. Reinstall the broker to configure it again (in case of a change in the domain controller or the LDAP server)
  2. Check the directory cluster settings in Portnox Cloud: Settings > Authentication Repositories > DIRECTORY INTEGRATION SERVICE > Directory domains
  3. Check if the local LDAP server is reachable from the broker: How to check if the LDAP Broker connects to the LDAP server
  4. Check the clock on the user device and the domain controller. If they are out of synchronization, for example, if one of them is not automatically updated using a time server, authentication problems may occur.
  5. If you want to use NTLMv2 authentication only and block NTLMv1 for security reasons, make sure that the user account for the Portnox LDAP Broker, which is used to connect to the domain controller, is a member of the Domain Admins security group, and has the following minimum permissions: DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. Otherwise, the Directory Broker will be unable to verify the password hash, and all NTLMv2 authentication attempts will fail.
  6. Check the broker logs: Where to find the LDAP Broker logs and status
Broker status: Misconfigured The directory cluster settings are missing or wrong. This is not a common status, such an issue can happen due to having old directory clusters with wrong settings, or if the cluster was deleted.
  1. Check the directory cluster settings in Portnox Cloud: Settings > Authentication Repositories > DIRECTORY INTEGRATION SERVICE > Directory domains
  2. Check if the local LDAP server is reachable from the broker: How to check if the LDAP Broker connects to the LDAP server
  3. Check the broker logs: Where to find the LDAP Broker logs and status
Broker status: Not updated The broker is an old version. This can happen due to communication issues or if a new version of broker was published but not installed.
  1. Check if the cloud servers are reachable from the broker: How to check if the LDAP Broker connects to the cloud
  2. Check if there is enough space on the disk of the Windows machine to install the new broker version.
  3. Check the broker logs: Where to find the LDAP Broker logs and status
  4. Install the new broker version manually
Broker status: Unreachable There are issues with establishing a relay connection.
  1. Check if the cloud servers are reachable from the broker: How to check if the LDAP Broker connects to the cloud
  2. Check if the local LDAP server is reachable from the broker: How to check if the LDAP Broker connects to the LDAP server
  3. Check the broker logs: Where to find the LDAP Broker logs and status
Broker status: Active The LDAP Broker seems to work properly, but there are still issues.
  1. Check if the cloud servers are reachable from the broker: How to check if the LDAP Broker connects to the cloud
  2. Check if the local LDAP server is reachable from the broker: How to check if the LDAP Broker connects to the LDAP server
  3. Check the broker logs: Where to find the LDAP Broker logs and status
Broker installation fails at Verifying PAP A domain-level group policy restricts NLTM authentication. LDAP Broker uses NLTM to bind to Active Directory over LDAP for PAP verification.

Adding LDAP Broker to the NTLM exception list in Group Policy:

  1. Open the Group Policy Management Console (GPMC) on the domain controller.

  2. Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.

  3. Locate and configure the policy: Network Security: Restrict NTLM: Add server exceptions in this domain.

  4. Add the hostname of the LDAP Broker server to the exception list.

  5. Apply the policy (gpupdate /force) or restart the LDAP Broker server.

  6. Rerun the LDAP Broker Setup Wizard. The Verifying PAP step should now complete successfully.
SSL (LDAPS) communication not working The domain controllers were defined using IP addresses.
  1. In Portnox Cloud, go to Settings > Authentication Repositories > DIRECTORY INTEGRATION SERVICE > Directory domains > Edit and in Domain Controllers (DC), define the domain controllers using FQDNs, not IP addresses
  2. Use a tool such as Ldp to validate that the domain controller is configured correctly with LDAPS and the certificate.
Multiple brokers configured but only one in Portnox Cloud The Windows virtual machines were cloned and have the same system GUID. Check the GUID in the following registry key: HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Cryptography > MachineGuid Create the Windows virtual machine for each broker from scratch, not by using the clone option.
AD/LDAP groups are not populated in Portnox Cloud. There is a log entry that says: Fail to access registry: Value cannot be null. The Windows registry was damaged during installation. Reinstall the broker.
Broker service not running The LDAP Broker service must be set to Automatic and the service must be started. Open the Windows Services console, look for Portnox™ Centraal Active Directory Broker, check its Properties, make sure that Startup type is set to Automatic, and click on the Start button.
Event logs: LDAP account 'apc' is missing. LDAP Broker installation is corrupt. Uninstall LDAP Broker using the Windows Control Panel. Download the latest version of LDAP Broker (Settings > Authentication Repositories > DIRECTORY INTEGRATION SERVICE > Download Portnox Cloud Directory Broker) and then install it.
During LDAP Broker update, a security tool may flag EXE files with random-looking names, for example kmcu3cji.suo.exe. These temporary EXE files are part of the process of building a new broker version. Portnox signs them and they are not harmful. Ignore the warnings from your security tool during the broker update about these temporary EXE files.
A device continues to authenticate successfully even after the user account has been removed from the Active Directory group mapped to a Cloud group. This behavior differs from the expected outcome, where removal from the AD group should revoke authentication.

Group membership changes in AD are not enforced immediately. The account used by the device will remain authenticated until the next successful AD synchronization or the next reauthentication.

If authentication still persists, the likely cause is cached authentication on the NAS device. The NAS may cache successful authentication results for a device or user. If the cache is not cleared or refreshed, the NAS may continue to allow access based on cached session data even after group removal.

As a workaround, create a new account in AD, add it to the appropriate group, and remove or disable the original account in both AD and Portnox Cloud.

Using RADIUS CoA (Change of Authorization) is the recommended long-term solution. RADIUS CoA allows the RADIUS server to dynamically enforce policy changes or disconnect active sessions without waiting for reauthentication or synchronization cycles.