Active Directory authentication to Advanced Threat Protection Manager fails following upgrade to version 3.2

Products

• Endpoint Detection and Response
• Advanced Threat Protection Platform

Issue/Introduction

You are unable to login to the Advanced Threat Protection (ATP) web interface via Active Directory (AD) credentials following an upgrade to version 3.2. Active Directory authentication was working prior to the upgrade. You are still able to login with a local administrator account. Should you attempt to update the Active Directory settings within ATP, then you may run into a certificate error.

• When you attempt to login to the ATP console you may receive the following error: "User name or password is incorrect"
• When you successfully logged in via a local account and try to change or re-add your Active Directory source you may receive the following error regardless of using "Validate Certificate": "Error: Certificate could not be used to validate Active Directory server."

Environment

• Advanced Threat Protection 3.2
• Active Directory Authentication was already configured prior to the upgrade with secure LDAPS (not LDAP) protocol.
  • You may also be using a certificate generated by an Internal CA or another Domain Controller.
• Non-secure LDAP is not in use

Cause

The SSL handshake is failing because the "Primary IP or Hostname" field does not match the Common Name (CN) or any of the Subject Alternative Name(s) on the LDAPS public certificate. This is required in version 3.2.

Resolution

1. Login to ATP via a local administrator account.
2. Edit the Active Directory configuration under Settings, Users, Active Directory tab.
3. Change the "Primary IP or hostname". This is often but not necessarily the FQDN or NETBIOS name of the Active Directory Server.
   • For self-signed LDAPS public certificates this is either the NETBIOS name (short name) or the FQDN of the active directory server
   • In some larger environments with multiple Active Directory servers, this may be a different name if a signed certificate is in use. Please check with your Active Directory administrator to get the correct CN.
4. If you use a certificate signed by an Internal CA, this is not currently supported with ATP 3.2. You will not be able to validate these certificates. This issue has been fixed in  Symantec Endpoint Detection and Response 4.0.