Troubleshooting Authentication

Testing authentication servers is possible using the tool located at Diagnostics > Authentication.

See also

Testing user authentication is a simple process:

  • Navigate to Diagnostics > Authentication

  • Select an Authentication Server

  • Enter a Username

  • Enter a Password

  • Click the Test button.

Note

This only performs a basic authentication test. Some special use cases, such as EAP, cannot be tested in this manner and may still fail when this test succeeds.

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.

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).

Tip

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 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 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=).

Troubleshooting 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 why a request failed. The system log at Status > System Logs may also contain information that hints at a resolution.

Troubleshooting 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 a capture is loaded in Wireshark, which can interpret the responses, as seen in Figure Sample LDAP Failure Capture.

../_images/usermanager-ldap-capture.png

Sample LDAP Failure Capture