LDAPProvider using LDAPS breaks after upgrade to 9.0.2+

    Applies to:
  • Legacy SecureAuth IdP
Deployment model:
  • On Premises
  • SecureAuth IdP Version Affected:  9.0.2+

    Description:  After an upgrade or migration, realms time out during authentication attempts when the data store is configured to connect to LDAP using LDAPS.  When looking through debug logs, you see that LDAPMembership calls successfully complete, but the process stops when the appliance tries to pull user attributes and you do NOT see LDAPProvider.GetProperties and LDAPProvider.SetProperties during the login attempt.

    Cause:  In older versions of the appliance, LDAPS is hard coded to use 636 when Connection Type of Secured or SSL is selected.  In newer versions of the appliance, this is no longer the case, and the appliance will default to port 389 unless a port number is explicitly defined in the Profile Provider section (using "Same as Above" for Profile Provider settings is insufficient and may fail).

    Resolution:  Explicitly define the port in the connection string.


    Original connection string - LDAP://fqdn.com/O=Store

    New connection string - LDAP://fqdn.com:636/O=Store


    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



    Please sign in to leave a comment.