Troubleshooting: Administrative Reset with History Check Fails with "The LDAP Server Is Unavailable"

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • On Premises
  • Version Affected: All
     
     

    Overview

    This article explains how to resolve an error where using the Password Reset option Administrative Reset with History Check fails with "Password was not changed Exception: The LDAP server is unavailable," even though the Test Connection on the Data tab works fine.

    The Password Admin reset with history page showing the error: Password was not changed Exception: The LDAP server is unavailable.

    • See Cause 1 - If this happens generally, regardless of connection type, it's a certificate mismatch caused by using a domain-based connection string.
    • See Cause 2 - If this only happens over LDAPS/SSL after upgrading from 9.1 or earlier to 9.2 or later, it's a changed POLICY_HINTS OID.

    These causes are not related, so a fix for one cause will not resolve the other cause.

     

    In this article


     

    Cause 1: Certificate Mismatch from a Domain-Based Connection String

    The password reset action connects using the connection string specified on the Data tab, which is usually the domain rather than a specific Domain Controller (DC). The DC that responds presents its own certificate, using its own FQDN, which does not match the domain-based connection string — causing a certificate mismatch and the connection to close.

     

    Resolution 1:

    To resolve this, edit the connection string to specify a Domain Controller directly instead of the domain:

    1. Open the Data tab.
    2. Edit the Connection String to specify a Domain Controller. For example, if the domain is wood.example.com and the DC is named mydc, the connection string becomes:
      LDAP://mydc.wood.example.local/DC=wood,DC=example,DC=local
      The Datastore Connection section with the Connection String field set to a Domain Controller-specific LDAP connection string.

     

    Cause 2: POLICY_HINTS OID Changed After Upgrading to 9.2 or Later

    This applies only when using LDAPS/SSL to connect to the datastore. After upgrading from 9.1 or earlier to 9.2 or later, the supported POLICY_HINTS OID changed to the standard value. If the datastore is still running an older Windows Server, its Domain Controller may still use the deprecated OID:

    • 1.2.840.113556.1.4.2239 = POLICY_HINTS
    • 1.2.840.113556.1.4.2066 = POLICY_HINTS_DEPRECATED

     

    Resolution 2:

    To resolve this:

    1. Confirm which OID the datastore's Domain Controller uses. One way to check is to connect to the datastore using the LDP tool and look at the supportedControl section.
    2. Apply the latest hotfix, since there have been minor changes to LDAPS.
    3. Open the web.config for the datastore realm used for password reset.
    4. In the Membership Provider section, alongside the other datastore settings, add a new ldapServerPolicyHintsOID attribute set to the POLICY_HINTS_DEPRECATED OID value:
      ldapServerPolicyHintsOID="1.2.840.113556.1.4.2066"
    5. Save and test.



     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.