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.
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:
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:
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.
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.
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
AP 10.0.0.2 sends a StartTLS packet, but the AD server 10.0.0.117 sends a LDAPError: Error Initializing SSL/TLS.
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.
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.
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.
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.
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 then 1139 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. firstname.lastname@example.org or just the sAMAccountName i.e. administrator without a prefix or suffix.
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 denied. In this case, verify the user account name is valid and that the admin account has read access to the OU containing the user.
Once the configuration above has been completed, the Meraki device should be able to communicate with the Active Directory server using TLS. If this fails, Microsoft offers the Ldp.exe tool to ensure that the LDAP service is running and compatible with the current certificate.
Please reference Microsoft documentation for error code details and troubleshooting assistance.
For more info on troubleshooting splash pages in general, please refer to our documentation regarding Splash Page Traffic Flow and Troubleshooting.