FortiGate LDAP Authentication with Active Directory: Configuration and Testing

Centralized identity management is critical for modern enterprise network security. Managing local user accounts across multiple firewalls introduces administrative overhead and security risks. Integrating your FortiGate firewall with Active Directory (AD) using the Lightweight Directory Access Protocol (LDAP) resolves this issue. It allows you to enforce centralized access policies, SSL VPN authentication, and administrative controls.

This guide walks you through a complete FortiGate LDAP Active Directory configuration. You will learn how to design, configure, test, and troubleshoot secure LDAP authentication (LDAPS) using both the FortiGate GUI and CLI.

Real-Life Scenario

An enterprise organization wants to eliminate local user database management on its edge FortiGate firewalls. The security team mandates that all remote SSL VPN users and internal corporate access policies authenticate against Microsoft Active Directory.

To comply with internal audit guidelines, cleartext LDAP traffic over TCP port 389 is strictly prohibited. The configuration must use Secure LDAP (LDAPS) over TCP port 636. Furthermore, FortiGate must validate the domain controller’s SSL certificate using an internal Enterprise Root Certificate Authority (CA).

Lab Topology

The diagram below illustrates the communication path between the user endpoint, the FortiGate firewall, and the redundant Microsoft Active Directory Domain Controllers.

+---------------------+
| Remote / LAN Client |
+----------+----------+
           |
           | Authenticates (SSL VPN / Firewall Policy)
           v
+-------------------------------------------------+
| FortiGate Firewall (lab-fw01)                   |
| Internal Interface: 10.0.1.254                  |
+--------------------+----------------------------+
                     |
                     | LDAPS Queries (TCP Port 636)
                     | Encrypted TLS Tunnel
                     v
  +------------------+------------------+
  |                                     |
  v                                     v
+-----------------------+     +-----------------------+
| Primary AD DC         |     | Secondary AD DC       |
| (lab-dc01.lab.local)  |     | (lab-dc02.lab.local)  |
| IP: 10.0.1.10         |     | IP: 10.0.1.11         |
+-----------------------+     +-----------------------+

Example Addressing and Objects

The table below details the LAB/EXAMPLE network parameters, directory paths, and service accounts used throughout this technical tutorial. You must adapt these values to match your production environment.

Prerequisites

Before starting the configuration, ensure the following requirements are met:

• Active Directory Domain Services (AD DS) is operational.
• An active Server Authentication certificate is installed on the Domain Controllers to support LDAPS (TCP 636).
• A dedicated Active Directory service account exists with a non-expiring password and read privileges for the domain directory tree.
• The Enterprise Root CA certificate (or intermediate CA chain) that signed the DC certificate is available in PEM or DER format.
• Network firewalls and Windows host firewalls permit TCP port 636 between FortiGate and the Domain Controllers.

Step-by-Step GUI Configuration

Follow these steps to configure secure LDAP authentication using the FortiGate GUI. Note that menu paths may vary slightly depending on your FortiOS firmware version.

Step 1: Import the Enterprise Root CA Certificate

FortiGate must trust the CA that issued the Domain Controller’s LDAPS certificate. Skipping this step prevents server identity validation when using encrypted connections.

1. Navigate to System > Certificates (or Security Profiles > Certificates in some FortiOS builds).
2. Click Import > CA Certificate.
3. Select File, browse to your Root CA certificate file, and upload it.
4. Verify that the imported certificate appears under the External CA Certificates list with a friendly name such as CA_Cert_Internal.

Step 2: Create the LDAP Server Object

Define the Active Directory connection parameters on the FortiGate.

1. Navigate to User & Authentication > LDAP Servers.
2. Click Create New.
3. Configure the primary connection details:
   • Name: lab-ad-ldaps
   • Server IP/Name: 10.0.1.10
   • Secondary Server IP/Name: 10.0.1.11
   • Server Port: 636
   • Common Name Identifier: sAMAccountName
   • Distinguished Name: DC=lab,DC=local
   • Bind Type: Regular
   • Username: CN=svc-fortigate,OU=ServiceAccounts,DC=lab,DC=local
   • Password: Enter the service account password.
4. Enable Secure Connection and select LDAPS.
5. Enable Certificate and select your imported CA certificate (CA_Cert_Internal).
6. Click Test Connectivity to verify basic IP reachability.
7. Click Test User Credentials, input a valid domain username and password, and click Test to verify authentication.
8. Click OK to save the configuration.

Step 3: Map Active Directory Groups to FortiGate User Groups

FortiGate policies control access using user groups rather than direct server objects.

1. Navigate to User & Authentication > User Groups.
2. Click Create New.
3. Set the Name to AD-VPN-Users.
4. Under Remote Groups, click Add.
5. Select lab-ad-ldaps from the Remote Server dropdown.
6. A browser window displays your Active Directory OU structure. Expand the tree, locate CN=VPN-Users,OU=Groups,DC=lab,DC=local, right-click it, and select Add Selected.
7. Click OK to finalize the group mapping.
8. Click OK to save the FortiGate User Group.

CLI Configuration

Configuring LDAP via the FortiGate Command Line Interface (CLI) provides exact control over advanced parameters, such as identity checking and secondary server configurations.

1. Configure the LDAP Server Object

config user ldap
    edit "lab-ad-ldaps"
        set server "10.0.1.10"
        set secondary-server "10.0.1.11"
        set port 636
        set cnid "sAMAccountName"
        set dn "DC=lab,DC=local"
        set type regular
        set username "CN=svc-fortigate,OU=ServiceAccounts,DC=lab,DC=local"
        set password "EXAMPLE_SECRET_PASS"
        set secure ldaps
        set ca-cert "CA_Cert_Internal"
        set server-identity-check enable
    next
end

2. Configure the FortiGate User Group

config user group
    edit "AD-VPN-Users"
        set member "lab-ad-ldaps"
        config match
            edit 1
                set server-name "lab-ad-ldaps"
                set group-name "CN=VPN-Users,OU=Groups,DC=lab,DC=local"
            next
        end
    next
end

3. Apply User Group to a Firewall Policy

config firewall policy
    edit 10
        set name "VPN-to-Internal-Access"
        set srcintf "ssl.root"
        set dstintf "port1"
        set action accept
        set srcaddr "SSLVPN_TUNNEL_ADDRS"
        set dstaddr "Internal_Subnet_10.0.1.0_24"
        set schedule "always"
        set service "ALL"
        set groups "AD-VPN-Users"
        set nat enable
    next
end

How the Traffic Flows

Understanding how FortiOS handles authentication traffic helps prevent misconfigurations and simplifies troubleshooting. The step-by-step process operates as follows:

1. Authentication Request: A client requests access through an SSL VPN tunnel or an authenticating firewall policy challenge.
2. TCP Connection & TLS Handshake: FortiGate initiates a TCP connection to the primary LDAP server IP (10.0.1.10) on port 636. If LDAPS is enabled, FortiGate initiates a TLS handshake and verifies the domain controller’s certificate against its imported CA store.
3. Service Account Bind: FortiGate issues an LDAP Bind request using the configured service account credentials (CN=svc-fortigate...).
4. User Directory Search: Once bound, FortiGate executes an LDAP search filter matching the user’s input against the Common Name Identifier: (&(objectCategory=person)(objectClass=user)(sAMAccountName=username)).
5. User Credentials Verification: After retrieving the user’s Distinguished Name (DN), FortiGate attempts a second LDAP Bind using the targeted user’s DN and the password supplied by the user.
6. Group Attribute Check: Upon successful user authentication, FortiGate queries the user’s memberOf attributes or checks group DN mappings.
7. Policy Authorization: FortiGate matches the returned group membership against internal objects (such as AD-VPN-Users). Access is granted, and the firewall policy permits traffic flow.

Verification

Always verify LDAP functionality from the FortiGate CLI using built-in testing tools before putting the configuration into production.

Test Authentication Server via CLI

Use the diagnose test authserver command to test LDAP binding, credential validation, and group retrieval in a single step.

diagnose test authserver ldap lab-ad-ldaps jdoe ConfidentialPassword123

Successful Output Example:

authenticate 'jdoe' against 'lab-ad-ldaps' succeeded!
Group membership(s) returned by LDAP server:
    CN=VPN-Users,OU=Groups,DC=lab,DC=local
    CN=Domain Users,CN=Users,DC=lab,DC=local

If the test succeeds, FortiGate confirmed the user’s password and successfully retrieved group memberships.

Check Active Firewall Authenticated Sessions

To view real-time authenticated users currently logged into the FortiGate, run:

diagnose firewall auth list

This command displays user IP addresses, assigned authentication groups, and session duration timers.

Troubleshooting

If LDAP authentication fails, follow this structured troubleshooting workflow to isolate the fault.

Workflow Diagram

[Network Reachability Check] -> [TLS / Certificate Check] -> [Service Account Bind] -> [User Auth & Group Match]

Step 1: Check Network Connectivity

Verify that FortiGate can route traffic to the Domain Controller on port 636:

execute ping 10.0.1.10

If the ping succeeds, verify the socket connection using packet sniffing:

diagnose sniffer packet any "host 10.0.1.10 and port 636" 4 10 local

Step 2: Debug the Authentication Daemon

The fnbamd (FortiGate Network Binding and Authentication Daemon) processes all authentication requests. Enabling debug traces on fnbamd provides full visibility into the LDAP request lifecycle.

Caution: Debugging can increase log volume and CPU utilization on high-traffic firewalls. Run debugs selectively and always turn them off after troubleshooting.

diagnose debug application fnbamd -1
diagnose debug enable

Now, execute a test login attempt. Inspect the output for specific error states:

• Certificate Errors: fnbamd_tls_connect failed indicates a trust issue. Verify that the Root CA is correctly uploaded and that server-identity-check matches the domain controller’s certificate subject name.
• Invalid Credentials: fnbamd_ldap_check_response - Code 49 indicates bad credentials for either the bind service account or the end user.
• Object Not Found: User not found indicates an incorrect search base DN or wrong CNID attribute.

Step 3: Cleanup Debug Commands

Always disable debugging once testing is complete:

diagnose debug disable
diagnose debug reset

Common Mistakes

• Incorrect Search Base DN: Setting the Base DN too restrictively (for example, pointing to a specific OU) prevents FortiGate from locating users located in other OUs or default containers like CN=Users.
• Using `userPrincipalName` Instead of `sAMAccountName`: If users log in with `username` rather than `username@domain.com`, the cnid setting must be set to sAMAccountName.
• Expired Service Account Password: Using an account subject to domain password expiration policies causes sudden LDAP authentication failures when the password expires.
• Mismatched SSL Certificates: Connecting to an IP address (10.0.1.10) while server-identity-check is enabled causes TLS verification failures if the certificate only lists the FQDN (`lab-dc01.lab.local`).
• Missing Intermediate Certificates: Supplying only the Root CA when the Domain Controller uses a certificate issued by a Subordinate/Issuing CA breaks the trust chain validation.

Production Considerations

To ensure high availability and performance in enterprise production environments, consider the following best practices:

1. Redundancy: Always configure a secondary (and optional tertiary) LDAP server in your FortiGate LDAP server object. FortiGate failover ensures uninterrupted login services if a primary Domain Controller undergoes maintenance.

2. Timeout and Connection Tuning: Adjust LDAP query timeouts for high-latency connections across WAN or IPsec links. Increase the timeout under CLI if complex Active Directory directory structures cause slow query responses:

config user ldap
    edit "lab-ad-ldaps"
        set timeout 5
    next
end

3. Active vs. Passive Authentication (LDAP vs. FSSO): Active LDAP authentication requires users to submit explicit credentials (e.g., VPN prompts or web portals). For seamless, transparent authentication for internal network access, evaluate Fortinet Single Sign-On (FSSO) alongside direct LDAP integrations.

Related FortiGate Guides

• FortiGate SSL deep inspection
• FortiGate security profiles
• FortiGate session troubleshooting
• FortiGate Syslog/SIEM

Summary

Integrating FortiGate with Active Directory using secure LDAP (LDAPS) provides robust, centralized authentication for network access control. Implementing server identity checks, configuring proper group mappings, and utilizing CLI debugging tools allows network engineers to build and maintain secure authentication structures easily.