Skip to main content

 

Cisco Meraki Documentation

Troubleshooting Active Directory Authentication with Splash Page

  1. Last updated
  2. Save as PDF

Overview

The Sign-on Splash page with Active Directory authentication (AD) uses Lightweight Directory Access Protocol (LDAP/over Transport Layer Security (TLS) to securely bind to a Global Catalog for authentication. Specifically, the access point (AP) performs a secure LDAP bind to the domain controller on Global Catalog TCP port 3268 using the admin credentials specified in the Cisco Meraki dashboard, then searches the directory for the user with the credentials entered on the splash page.

Examining LDAP interface events in the Windows Directory Service Event log can help determine whether a bad password or bad username is causing 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.
Directory-Service.png

Before running the widget test or trying to authenticate via the splash page to generate logs, clear or filter the existing logs to the last hour. Filtering makes it easier to locate newer events. Right-click the Directory Service log and select Clear log, then perform authentication attempts.
Clear-log.png
After LDAP events have been generated, piece them together to isolate the cause of the authentication failure as described in Section 2.

Troubleshooting authentication failures

Authentication failures on the Sign-on Splash page with Active Directory may occur for several reasons:

  • Bad admin credentials
  • Bad user credentials

Troubleshooting steps

Bad passwords (admin or user)

Use the test widget to determine whether the admin or user password is invalid. In the Windows Event log, Event 1174 displays the Security Identifier (SID) of the account using the bad password.

If the AD admin password or the user account password is incorrect, events appear in the following order:

  1. Events 1138 and 1139: These events appear whenever an LDAP search occurs.

Events-1138.png

Events-1139.png

 

  1. Event 1174: This event follows immediately after a bad password is entered, showing the SID of the account that attempted authentication with a bad password.

Event-1174.png

 

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

SID-1174-Event.png

 

  1. Event 1535: This event appears after Event 1174 and indicates that an LDAP error occurred.

Event-1535.png

 

  1. Event 1215: This event indicates that the LDAP client closed the connection.

Event-1215.png

After identifying the account with the bad password using the SID in Event 1174, update the password for that account and retry authentication.

Active Directory admin account name is invalid

When the AD 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."

  • 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 .
  • Finally the LDAP client will close the connection resulting in a 1215 event. 

To resolve this issue, verify that the account exists in AD. Use one of the following formats for the admin account name:

Login username is invalid

When the user account logging into the splash page does not exist in the directory, the username is entered incorrectly, or the admin account does not have read access to the OU containing the user, the LDAP search completes successfully with no error-based events.

  • Events 1138 and 1139: These events are logged after a successful LDAP search.

The test widget will display "bad user password" and the Sign-on Splash page will show Access denied.

To resolve this issue:

  • Verify that the user account name is valid in AD.
  • Confirm that the admin account has read access to the OU containing the user.

Testing LDAP

After completing the configuration above, the Cisco Meraki device should be able to communicate with the AD server using TLS. If communication fails, use the Microsoft Ldp.exe tool to verify that the LDAP service is running and compatible with the current certificate.

Refer to Microsoft documentation for error code details and additional troubleshooting assistance.

Additional resources

For more information on troubleshooting splash pages, refer to the documentation on Splash Page Traffic Flow and Troubleshooting.