GFI Support Home Start a conversation Sign in
Start a conversation
  1. KerioControl
  2. KerioControl - Directory Services
  3. Articles

Resolving "Strong(er) Authentication Required" Error When Joining Active Directory in Kerio Control

Overview

When joining Kerio Control to a Microsoft Active Directory domain, the attempt may fail with LDAP result code 8: "Strong(er) authentication required". This error means the Domain Controller's LDAP security policy requires encrypted or signed connections, and Kerio Control is attempting to bind using an authentication method that does not meet those requirements.

This article applies to all currently supported versions of GFI Kerio Control connected to Windows Server Active Directory (2016, 2019, 2022, or 2025).

You may also encounter LDAP result code 49 ("Invalid credentials") or "Connect error" messages alongside the primary error. These are typically secondary symptoms of the same underlying configuration mismatch.

In This Article

Symptoms

  • Kerio Control fails to join the Active Directory domain; the admin interface reports a connection error.
  • Debug logs show: Can't bind to LDAP server using SASL/DIGEST-MD5 authentication. Message: Strong(er) authentication required, code: 8.
  • Simple-bind attempts also fail: Can't bind to the LDAP server using simple authentication. Message: Strong(er) authentication required, code: 8.
  • You may additionally see Invalid credentials, code: 49 or LdapProvider: domain controller(s) were tried, but no one is reachable in the same log session.
  • ADConnector: testJoin() - Disconnected appears, confirming the join never completed.

Common Causes

  1. Domain Controller requires LDAP signing or channel binding. Starting with Windows Server 2019 (and enforced by default in Windows Server 2025), Microsoft Domain Controllers reject unsigned or unencrypted LDAP binds. If Kerio Control is attempting a plain LDAP connection on port 389, the DC will refuse the bind with code 8.
  2. No valid Server Authentication certificate on the DC. Even when Kerio Control is configured to use encrypted LDAP, the connection will fail if the Domain Controller does not have a certificate suitable for LDAPS.
  3. Incorrect or expired bind-account credentials. A locked, expired, or mistyped service account will trigger code 49 alongside the primary error.
  4. Time skew between Kerio Control and the Domain Controller. Kerberos authentication requires the clocks on both systems to be within five minutes of each other. A larger drift causes authentication to fail silently or with misleading error codes.

Resolution Steps

Step 1: Configure Kerio Control to Use LDAPS (Port 636)

  1. Log in to the Kerio Control administration interface.
  2. Navigate to Configuration > Domains and User Login > Directory Services.
  3. In the directory service settings, change the LDAP port from 389 to 636.
  4. Enable the Use encrypted connection (LDAPS) checkbox.
  5. Click Test Connection to verify.

If the test succeeds, proceed to join the domain. If it fails, continue with Step 2.

Step 2: Verify the Domain Controller Has a Valid LDAPS Certificate

LDAPS requires the Domain Controller to present a Server Authentication certificate. To verify:

  1. On the Domain Controller, open certlm.msc (Local Computer Certificate Store).
  2. Navigate to Personal > Certificates.
  3. Confirm a certificate exists with:
    • Intended Purpose: Server Authentication
    • Subject / Subject Alternative Name matching the DC's FQDN
    • A valid (non-expired) validity period
  4. If no suitable certificate exists, either enroll one through your internal Certificate Authority or generate a self-signed certificate for testing: 
    New-SelfSignedCertificate -DnsName "dc.example.com" -CertStoreLocation "cert:\LocalMachine\My" -KeySpec KeyExchange
  5. Restart the Active Directory Domain Services service (or reboot the DC) for the new certificate to take effect.

Step 3: Verify Bind Account Credentials

  1. On the Domain Controller, open Active Directory Users and Computers.
  2. Locate the service account used by Kerio Control for LDAP binding.
  3. Confirm the account is:
    • Not locked out
    • Not expired
    • Not disabled
    • Password has not expired
  4. In Kerio Control, re-enter the bind account credentials (username in user@domain format and password) and click Test Connection.

Step 4: Synchronize Time Between Kerio Control and the Domain Controller

Kerberos authentication fails if the clock difference between the two systems exceeds five minutes.

  1. In Kerio Control, navigate to Configuration > Advanced Options > Time Settings (or the equivalent NTP configuration section).
  2. Set the NTP server to the Domain Controller's IP address or to a reliable external NTP source (e.g., pool.ntp.org).
  3. On the Domain Controller, confirm it is also synchronized to a reliable time source: 
    w32tm /query /status
  4. Verify both systems show the same time (within a few seconds) before retrying the domain join.

Additional Information

  • Microsoft LDAP signing enforcement: Microsoft has progressively tightened LDAP security. As of March 2020 (and reinforced in later updates), Domain Controllers may reject simple LDAP binds by default. Always use LDAPS (port 636) or LDAP with Start TLS when connecting third-party appliances to Active Directory.
  • Checking the DC's LDAP signing policy: On the Domain Controller, open Local Security Policy > Local Policies > Security Options and check Domain controller: LDAP server signing requirements. If set to Require signing, only signed or encrypted connections will be accepted.
  • Diagnosing from Kerio logs: Enable debug-level logging in Kerio Control (Configuration > Advanced Options > Debug Logging), reproduce the join failure, and download the support information package. Look for {auth} ADConnector entries to trace the exact failure point.
  • Firewall considerations: Ensure port 636 (TCP) is open between Kerio Control and the Domain Controller. Standard LDAP on port 389 is not sufficient when the DC requires encryption.

FAQ

Q1: Can I lower the DC's LDAP signing requirement instead of switching to LDAPS?
A1: Technically yes — setting LDAP server signing requirements to None on the DC will allow unsigned binds. However, this weakens your domain's security posture and is not recommended. Microsoft is actively deprecating unsigned LDAP in favor of mandatory signing. Configuring Kerio Control to use LDAPS is the correct long-term approach.

Q2: I switched to port 636 but the connection still fails. What should I check?
A2: Verify that (1) the DC has a valid Server Authentication certificate (see Step 2), (2) port 636 is not blocked by a firewall between Kerio Control and the DC, and (3) the certificate's Subject or SAN matches the hostname Kerio Control is using to reach the DC.

Q3: What does LDAP result code 49 ("Invalid credentials") mean alongside code 8?
A3: Code 49 indicates the credentials themselves were rejected. When seen together with code 8, it usually means Kerio Control retried the connection with different authentication methods (SASL, simple bind) and at least one attempt used incorrect or outdated credentials. Re-entering the bind account password in Kerio Control typically resolves this secondary error once LDAPS is properly configured.

Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Ciprian Nastase

  2. Posted

Comments