Technical Tip: Setting up a redundant connection to the LDAP servers

[mturic]

Description

This article describes how to try to set up for redundancy two individual LDAP entries pointing to the same domain and with the same settings can cause authentication issues.
This article describes the preferred way to set up redundant LDAP access on a FortiGate.

Scope

FortiGate.

Solution

When setting up two identical LDAP entries for redundancy, there can occur various authentication issues, especially in more complex environments as both LDAP servers would be set in a usergroup with the same group filter.

For example, with the following setup:

config user ldap
    edit "dc01"
        set server "10.0.0.10"
        set cnid "sAMAccountName"
        set dn "dc=mt-test,dc=local"
        set type regular
        set username "mt-test\\ldapadmin"
        set password <password>
    next
    edit "dc02"
        set server "10.0.0.11"
        set cnid "sAMAccountName"
        set dn "dc=mt-test,dc=local"
        set type regular
        set username "mt-test\\ldapadmin"
        set password <password>
    next
end
config user group
    edit "maximal"
        set member "dc01" "dc02"
        config match
            edit 1
                set server-name "dc01"
                set group-name "CN=maximal,CN=Users,DC=mt-test,DC=local"
            next
            edit 2
                set server-name "dc02"
                set group-name "CN=maximal,CN=Users,DC=mt-test,DC=local"
            next
        end
    next
end

When checking for a user this will cause the FortiGate to check at the same time on both domain controllers for the same credentials.
In most cases when the credentials are correctly entered, this will work and the user will be authenticated successfully.

However, if the credentials are not correctly entered then FortiGate will send the same incorrect credentials twice (or more, depending on the number of LDAP entries added to the group) and it can lock the user’s AD account with just one single login attempt via the FortiGate:

[2245] handle_req-Rcvd auth req 976192257 for testuser in maximal opt=00000500 prot=10
[397] __compose_group_list_from_req-Group 'maximal'
[614] fnbamd_pop3_start-testuser
[341] radius_start-Didn't find radius servers (0)
[718] auth_tac_plus_start-Didn't find tac_plus servers (0)
[1109] __fnbamd_cfg_get_ldap_list_by_group-Loading LDAP server 'dc01' for usergroup 'maximal' (3)
[1109] __fnbamd_cfg_get_ldap_list_by_group-Loading LDAP server 'dc02' for usergroup 'maximal' (3)
[1607] fnbamd_ldap_init-search filter is: sAMAccountName=testuser
[1616] fnbamd_ldap_init-search base is: dc=mt-test,dc=local
[991] __fnbamd_ldap_dns_cb-Resolved dc01(idx 0) to 10.0.0.10
[1059] __fnbamd_ldap_dns_cb-Still connecting.
[1607] fnbamd_ldap_init-search filter is: sAMAccountName=testuser
[1616] fnbamd_ldap_init-search base is: dc=mt-test,dc=local
[991] __fnbamd_ldap_dns_cb-Resolved dc02(idx 0) to 10.0.0.11
[1059] __fnbamd_ldap_dns_cb-Still connecting.
[556] create_auth_session-Total 2 server(s) to try
[941] __ldap_connect-tcps_connect(10.0.0.10) is established.
[815] __ldap_rxtx-state 1(StartTLS)
[860] fnbamd_ldap_send-sending 31 bytes to 10.0.0.10
[872] fnbamd_ldap_send-Request is sent. ID 1
[941] __ldap_connect-tcps_connect(10.0.0.11) is established.
[815] __ldap_rxtx-state 3(Admin Binding)
[204] __ldap_build_bind_req-Binding to 'mt-test\ldapadmin'
[860] fnbamd_ldap_send-sending 38 bytes to 10.0.0.11
[872] fnbamd_ldap_send-Request is sent. ID 1
[815] __ldap_rxtx-state 2(StartTLS resp)
[903] __fnbamd_ldap_read-Read 8
[1009] fnbamd_ldap_recv-Leftover 2
[903] __fnbamd_ldap_read-Read 38
[1083] fnbamd_ldap_recv-Response len: 40, svr: 10.0.0.10
[764] fnbamd_ldap_parse_response-Got one MESSAGE. ID:1, type:extended-result
[799] fnbamd_ldap_parse_response-ret=0
[882] __ldap_rxtx-Change state to 'Connecting'
[941] __ldap_connect-tcps_connect(10.0.0.10) is established.
[815] __ldap_rxtx-state 3(Admin Binding)
[204] __ldap_build_bind_req-Binding to 'mt-test\ldapadmin'
[860] fnbamd_ldap_send-sending 38 bytes to 10.0.0.10
[872] fnbamd_ldap_send-Request is sent. ID 2
[815] __ldap_rxtx-state 4(Admin Bind resp)
[903] __fnbamd_ldap_read-Read 8
[1009] fnbamd_ldap_recv-Leftover 2
[903] __fnbamd_ldap_read-Read 14
[1083] fnbamd_ldap_recv-Response len: 16, svr: 10.0.0.11
[764] fnbamd_ldap_parse_response-Got one MESSAGE. ID:1, type:bind
[799] fnbamd_ldap_parse_response-ret=0
…
[1083] fnbamd_ldap_recv-Response len: 104, svr: 10.0.0.10
[764] fnbamd_ldap_parse_response-Got one MESSAGE. ID:4, type:bind
[786] fnbamd_ldap_parse_response-Error 49(80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839)
[799] fnbamd_ldap_parse_response-ret=49
[882] __ldap_rxtx-Change state to 'Done'
[815] __ldap_rxtx-state 21(Done)
[860] fnbamd_ldap_send-sending 7 bytes to 10.0.0.10
[872] fnbamd_ldap_send-Request is sent. ID 5
[725] __ldap_stop-svr 'dc01'
[53] ldap_dn_list_del_all-Del CN=Test User,OU=Users,DC=mt-test,DC=local
[3012] fnbamd_ldap_result-Continue pending for req 976192257
[815] __ldap_rxtx-state 6(User Bind resp)
[903] __fnbamd_ldap_read-Read 8
[1009] fnbamd_ldap_recv-Leftover 2
[903] __fnbamd_ldap_read-Read 102
[1083] fnbamd_ldap_recv-Response len: 104, svr: 10.0.0.11
[764] fnbamd_ldap_parse_response-Got one MESSAGE. ID:3, type:bind
[786] fnbamd_ldap_parse_response-Error 49(80090308: LdapErr: DSID-0C0903D3, comment: AcceptSecurityContext error, data 52e, v3839)
[799] fnbamd_ldap_parse_response-ret=49
[882] __ldap_rxtx-Change state to 'Done'
[815] __ldap_rxtx-state 21(Done)
[860] fnbamd_ldap_send-sending 7 bytes to 10.0.0.11
[872] fnbamd_ldap_send-Request is sent. ID 4
[725] __ldap_stop-svr 'dc02'
[53] ldap_dn_list_del_all-Del CN=Test User,OU=Users,DC=mt-test,DC=local
[182] fnbamd_comm_send_result-Sending result 1 (error 0, nid 0) for req 976192257
[710] destroy_auth_session-delete session 976192257

The solution to avoid such scenarios is to implement redundant LDAP setup properly, within one LDAP entry. Two redundant LDAP servers can be specified, secondary and tertiary:

secondary-server                                             <----- Secondary LDAP server CN domain name or IP.
tertiary-server                              <----- Tertiary LDAP server CN domain name or IP.

With this setup, the secondary LDAP server will only be contacted if the primary is not reachable.
This can however prolong the time needed for the authentication as the first LDAP server needs to time out before the second one is contacted.

config user ldap
    edit "dc01"
        set server "10.0.0.10"
        set secondary-server "10.0.0.11"
        set cnid "sAMAccountName"
        set dn "dc=mt-test,dc=local"
        set type regular
        set username "mt-test\\ldapadmin"
        set password <password>
    next
end