Authored by: Support.com Tech Pro Team
How to Troubleshoot Authentication on Netgate Router
Testing authentication servers is possible using the tool located at Diagnostics > Authentication.
Testing user authentication is a simple process:
The firewall will attempt to authenticate the user against the chosen server, then it prints the results. The best practice is to try this at least once before attempting to use the server.
If the server returned a set of groups for the user, and the groups exist locally with the same name, the GUI prints the names of the groups in the test results.
If the firewall receives an error when testing authentication, double-check the credentials and the server settings, then make any necessary adjustments and try again.
LDAP DN and Related SettingsLDAP DN and Related Settings
For LDAP authentication servers, first, ensure the base DN and similar settings match those configured on the LDAP server. Check the LDAP server for more information.
For Base DN, it’s common to use the root of the LDAP tree but in most cases, the Entire Subtree must also be selected for the Search Scope.
Authentication Containers vary by LDAP implementations and setup. On Windows, it is commonly CN=Users,DC=example,DC=com
, but it may vary. Try using an LDAP browser or similar software to locate the correct container.
LDAP path components are not case sensitive, so CN=Administrator
is equivalent to cn=administrator
.
Bind Credentials
When using authenticated (Not anonymous) binds, the username can be the short name (e.g. DOMAIN\User
for AD) or a full LDAP specification for a user (e.g. CN=administrator,CN=Users,DC=example,DC=com
).
The full DN of a Windows AD bind user can be found by navigating to the user in ADSI Edit found under Administrative Tools on the Windows server.
For a production setup, an unprivileged user should be used for binding if possible, and not an AD Administrator-level account. Such an unprivileged user may need sufficient permissions to attempt binding as other users and access the LDAP directory.
Another common mistake with group membership is not specifying the Entire Subtree for the Search Scope Level.
Active Directory Group Membership
Depending on how the Active Directory groups were made, the way they are specified may be different for things like Authentication Containers and/or Extended Query. For example, a traditional user group in AD is exposed differently to LDAP than a separate Organizational Unit.
ADSI Edit found under Administrative Tools on the Windows server can locate the DN for a given group.
Extended Query
The most common mistake with Extended Query is that the given directive fails to include both the item to be searched as well as how, such as:
memberOf=CN=VPNUsers,CN=Users,DC=example,DC=com
Note that in the above example the DN of the group is given along with the restriction (memberOf=
).
Connection-Related Issues (non-SSL/TLS)
Make sure that the LDAP server is listening on the expected port, and that connectivity to the LDAP server network is functional.
Performing a packet capture filtered on the LDAP server IP address and port will help track down the problem. Tools such as Wireshark can interpret LDAP packets and help diagnose queries and failures.
Connection-Related Issues (SSL/TLS)
By far the most troublesome connection type is LDAP+SSL/TLS (ldaps) due to its strict security and validation standards.
When connecting to LDAP with SSL/TLS, the hostname given for the server is also used to verify the server certificate. The server certificate SAN entries and/or CN must include its hostname, and that hostname must resolve to the LDAP server IP address, e.g. CN=ldap.example.com
, and ldap.example.com
is 192.168.1.5
.
If an IP address has been entered for the hostname of the LDAP server, it will not work unless that IP address happens to also be the CN or a SAN of the server certificate.
If this must be worked around, it is possible to create a DNS host override in the DNS forwarder for <common name of the cert>.<firewall domain name>
. That assumes that the CN is in a format that could actually be a hostname, or that the hostname in question is present in a SAN entry on the server certificate.
When using port 636
for SSL/TLS, the firewall uses an ldaps://
URL, not STARTTLS. Ensure that the LDAP server is listening on the correct port with the correct mode. For STARTTLS, use port 389
.
The most important factor in making sure that it is possible to communicate with the LDAP server over SSL/TLS is that the correct CA certificate has been imported into the firewall, and is chosen on the LDAP settings. The key is not required, only the CA certificate.
If the LDAP server certificate CA is part of a chain, or there is an intermediate CA, every CA certificate in the chain must be imported into the Certificate Manager.
Confirm that the certificates are otherwise valid, for example, they are not expired or set to be valid in the future.
via Server Logs
Authentication failures are typically logged by the target server (FreeRADIUS, Windows Event Viewer, etc), assuming the request is making it all the way to the authentication host. Check the server logs for a detailed explanation of why a request failed. The system log at Status > System Logs may also contain information that hints at a resolution.
via Packet Captures
Packet captures (Packet Capturing) can be invaluable for diagnosing errors as well. If an unencrypted method (RADIUS, LDAP without SSL/TLS) is in use, the actual password being used may not be visible but enough of the protocol exchange can be seen to determine why a request is failing to complete. This is especially true when capture is loaded in Wireshark, which can interpret the responses, as seen in Figure Sample LDAP Failure Capture.
Sample LDAP Failure Capture