Troubleshooting Active Directory authentication with Sign-on Splash page

Sign-on Splash page with Active Directory authentication uses LDAP/TLS to securely bind to a Global Catalog for authentication. Specifically, the AP performs a secure LDAP bind to the Domain controller on Global Catalog TCP port 3268 using the admin credentials specified in Dashboard and searches the directory for the user with the credentials entered into the splash page. When errors occur the Sign-on Splash page will show "Access denied" for wireless clients attempting to authenticate, and Dashboard will also show error messages as shown below. 

Authentication failures with Sign-on Splash page fall into two categories.

1. Failure to connect to the Active Directory server

When a connection failure occurs, the test widget on Configure > Access control provides a link to the APs that "failed to connect."

 The root causes of connection failures are:

a) APs in Dashboard are configured to use an Active Directory server that is unreachable over TCP port 3268 or is not a Global Catalog. 

b) The Active Directory server does not have a digital certificate installed for LDAP using TLS.

2. Failure to authenticate

When an authentication failure occurs, the test widget on Configure > Access control reports "bad admin password" 

or "bad user password."

In addition, an "authorization" failure will appear in Dashboard on the Login attempts page.

The root causes of authentication failures are:

a) Invalid Active Directory admin username, password or both.

b) Invalid Login username, password or both.

c) The Active Directory Admin does not have read access to the OU containing the user object. 

Troubleshooting Method

The flow chart below outlines the recommended method for troubleshooting Active Directory Sign-on issues given the above information. The remaining portion of this article describes the steps necessary to follow this procedure.  

Troubleshooting a connection failure

When the Sign-on Splash page returns Access denied, run the test widget on Configure > Access control with the same user credentials. If the widget reports a connection failure, begin troubleshooting connectivity between the reported APs and the AD server. 

1. Check IP connectivity between the reported APs and the configured AD server. Ping the AD server from the AP in question using Live Toolsthen try pinging the AP from the AD server. Successful ping tests verify IP connectivity between endpoints.

2. Run the test widget while taking simultaneous packet captures from the AD server using Wireshark and the wired interface of the AP using Dashboard. These captures are analyzed in Wireshark and can be used to verify if the AD server is receiving TCP packets from the the AP on TCP port 3268 and whether or not the server is responding appropriately.

3. Analyze the capture taken on the AD server using the following Wireshark filter tcp.port==3268 and ip.addr==X.X.X.X, where X.X.X.X is the IP address of the AP. If the AD server replies to TCP SYN packet on port 3268 with a TCP RST, it is likely the AD server is not a Global Catalog. In this instance enable the Global Catalog role on the AD server. 

Figure 1: AD server 10.0.0.116 replies to the AP 10.0.0.117 with a TCP RST because it is not listening on TCP port 3268

4. If the packet capture shows the AD server sending an "Error initializing SSL/TLS" in response to the APs StartTLS packet, then the AD server does not have a valid digital certificate installed. In this case you will need to install a valid digital certificate on the AD server.

Figure 2: AP 10.0.0.2 sends a StartTLS packet, but the AD server 10.0.0.117 sends a LDAPError: Error Initializing SSL/TLS.

5. Firewalls can also cause connection failures. If the server is a Global Catalog but an TCP RST or ICMP "Destination Unreachable Communication administratively prohibited" is returned by the AD server, make sure TCP port 3268 is opened inbound on the local firewall. If either of these messages shows up on a capture taken from the AP but not on the AD server, there could be an intermediate firewall blocking access to the AD server. If there are no packets from the AP when analyzing the packet capture taken from the AD server, check the packet capture taken from the AP. If you see packets being sent from the AP to the AD server on TCP 3268 but no response, then there may be an intermediate firewall silently blocking communication. 

Troubleshooting authentication failures

Examining LDAP interface events in the Windows Directory Service Event log can help determine if a bad password or bad username is the cause of the authentication failure. To enable LDAP debugging logs on the Domain Controller, set the LDAP Interface Events to verbose using DWORD value 5 in the Windows registry. Once LDAP events have been enabled, open the Windows Event Viewer and navigate to Applications and Services Logs > Directory Service.

Before running the widget test or trying to authenticate via the splash page to generate some logs, clear the older logs or filter the current logs over the last hour. This will make it easier to locate the newer events. Right click the Directory Service log and choose Clear log. Then perform authentication attempts.




After LDAP Events have been generated they can be pieced together to isolate the cause of the authentication failure as described below. 

Bad passwords (Admin or User)

When all users are unable to authenticate to the splash page, it is most likely a bad admin credentials. If some users are able to authenticate then it is probably bad user credentials. Either way the test widget can be used to determine if the admin or the user password is invalid. In the Windows Event log, the SID of the account using the bad password will be shown in a event 1174. If the Active Directory admin password or the user account password is incorrect you will see Events in the following order.

1. Events 1138 and 1139 always appear when a LDAP search occurs, as shown below. 

2. When a bad password is entered, an Event 1174 will immediately follow, showing the SID of the account that attempted to use a bad password. 

You can use the SID specified in the 1174 Event and match it to the user object (Admin or user) properties in Active Directory Users and Computers.

3. Event 1535 will appear after the 1174 and tell you an LDAP error occurred.

4. Event 1215 shows the LDAP client closed the connection. 

Whichever account SID was specified in the 1174 event is the one that had a bad password. Make sure to use the correct password and try again.

Active Directory Admin account name is invalid

If the Active Directory admin name is invalid or does not exist in the directory all users will fail to authenticate through the splash page and the test widget will report "bad admin password" (previously shown). A 1174 event will not appear because the initial bind request failed. You will see Events 1138 then1139 immediately followed by a 1535 LDAP error event (previously shown). Finally the LDAP client will close the connection resulting in a 1215 event. In this case, verify the account exists in Active Directory. Try using the UPN i.e. administrator@mydomain.local or just the sAMAccountName i.e. administrator without a prefix or suffix.

Login username is invalid

If the user account logging into the splash page does not exist in the directory, the username is being entered incorrectly, or the Admin account does not have access to OU containing the user, an LDAP search will complete successfully with no error based Events. Events 1138 and 1139 will be logged when a successful LDAP search has occurred, however a "bad user password" (previously shown) will appear in the test widget and the Sign-on Splash page will alert Access