KB ID 0001733
Problem
Here’s a brief one that tripped me up a couple of weeks ago, I was deploying FortiGate LDAPS authentication for some FortiClient SSL VPN connections into a FortiGate firewall like so;
Despite my best efforts I was getting authentication failures? If I tested the username and password in the GUI web management portal, that worked fine?
Testing FortiGate LDAPS
First step is to test authentication at command line, like so;
Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' failed!
Note: My-DC is the domain controller, test, user is the username, and Password123 is the password for my AD user. (The fact I need to explain that is depressing, but c’est la vie).
So despite what the GUI is telling me, authentication is actually failing, remember I’m using LDAPS, so the FortiGate needs to have the CA certificate, (that issued the Kerberos certificates on my domain controller(s)), in its trusted CA list! And TCP port 636 needs to be open between the firewall and the domain controllers.
Debugging FortiGate LDAPS
So now we need to debug what’s going on;
Forti-FW # diagnose debug enable Forti-FW # diagnose debug application fnbamd 255 Debug messages will be on for 30 minutes.
Then simply attempt to authenticate via FortiClient, or recall the ‘diag test’ command from above.
Forti-FW # diag test auth ldap My-DC test.user Password123
[1932] handle_req-Rcvd auth req 1296531457 for test.user in My-DC opt=0000001b prot=0
[424] __compose_group_list_from_req-Group 'My-DC', type 1
[617] fnbamd_pop3_start-test.user
[970] __fnbamd_cfg_get_ldap_list_by_server-
[976] __fnbamd_cfg_get_ldap_list_by_server-Loaded LDAP server 'My-DC'
[1131] fnbamd_cfg_get_ldap_list-Total ldap servers to try: 1
[1713] fnbamd_ldap_init-search filter is: sAMAccountName=test.user
[1722] fnbamd_ldap_init-search base is: dc=testbench,dc=co,dc=uk
[1146] __fnbamd_ldap_dns_cb-Resolved My-DC:192.168.1.122 to 192.168.1.122, cur stack size:1
[919] __fnbamd_ldap_get_next_addr-
[1152] __fnbamd_ldap_dns_cb-Connection starts My-DC:192.168.1.122, addr 192.168.1.122 over SSL
[874] __fnbamd_ldap_start_conn-Still connecting 192.168.1.122.
[591] create_auth_session-Total 1 server(s) to try
[1097] __ldap_connect-tcps_connect(192.168.1.122) failed: ssl_connect() failed: 337047686 (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed).
[930] __ldap_error-My-DC:192.168.1.122, addr 192.168.1.122
[725] __ldap_stop-Conn with 192.168.1.122 destroyed.
[919] __fnbamd_ldap_get_next_addr-
[902] __ldap_try_next_server-No more server to try for 'My-DC'.
[785] __ldap_done-svr 'My-DC'
[755] __ldap_destroy-
[2870] fnbamd_ldap_result-Error (3) for req 1296531457
[217] fnbamd_comm_send_result-Sending result 3 (nid 0) for req 1296531457, len=2044
authenticate 'test.user' against 'My-DC' failed!
Forti-FW # [747] destroy_auth_session-delete session 1296531457
[755] __ldap_destroy-
[1764] fnbamd_ldap_auth_ctx_free-Freeing 'My-DC' ctx
[2099] fnbamd_ldap_free-Freeing 'My-DC'
OK so it’s SSL related? For SSL to work you need the following;
- To trust the CA that issued the certificate
- To be able to resolve (via DNS) the common name (or Subject Alternative Name) on the certificate
- If you’ve specified the LDAP server by IP address the IP address of the server needs to be on the certificate as a Subject Alternative Name (SAN).
- Your firewall and the AD/LDAP server need to have compatible SSL ciphers.
So I had number 1 covered, and the chance of it being number 4 are rare, (server and firewall are fully updated).
So my problem was initially number 2 I’d specified the LDAPS server via its internal IP. I needed to use its FQDN, then of course the firewall needed to be able to resolve that IP with a DNS lookup (try execute ping server-name.doman-name if you’re unsure!)
Forti-FW # execute ping win-server.testbench.co.uk
Unable to resolve hostname. <---OOPS THAT'S NOT GOOD!
Forti-FW # execute ping 192.168.1.122 <---CONNECTIVITY IS OK!
PING 192.168.1.122 (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=5.4 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.0 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=1.9 ms
^C
--- 192.168.1.122 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.9/3.1/5.4 ms
Once DNS was setup correctly;
Forti-FW # execute ping win-server.testbench.co.uk
PING win-server.testbench.co.uk (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=1.9 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.3 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=2.1 ms
^C
--- win-server.testbench.co.uk ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss <---BOOM THAT'S BETTER
round-trip min/avg/max = 1.9/2.1/2.3 ms
Then retest.
Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' succeeded!
Group membership(s) - CN=GS-VPN-Users,OU=Securty-Groups,DC=testbench,DC=co,DC=uk
CN=Domain Users,CN=Users,DC=testbench,DC=co,DC=uk
Related Articles, References, Credits, or External Links
NA
07/06/2021
What happens when dc cert changes i.e. at the time of cert renewal, do I have to deploy new cert on fortigate
09/06/2021
Nothing – it’s the root CA cert that the firewall needs – (that issued the DC cert)