WARNING: Portal for ArcGIS cannot connect to Active Directory LDAP server at ldaps

[ZacharyHart]

 We use Active Directory authentication (not using LDAP). There are two errors in sequence; see below.

• The only other post I've found related to this involves IWA.
• I have been assured by our IT provider that all Domain Controllers are Global Catalog Servers.
• We don't have any authentication issues as a result of this, but it is a curious and troubling warning.

[ChristopherPawlyszyn]

Have you tried connecting to the LDAPS port for global catalogs (3269) using another method such as ldp.exe?

Ldp | Microsoft Docs
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc...

That may give you some more information about why the connection is failing. With a connection reset error, it is possible the connection is being blocked by or timing-out on a firewall (either internal or external to the domain controller in question). The Active Directory connection does use LDAP to query the AD structure for users/groups, and connections will be made on 3269, 3268, 636, and 389, depending on whether LDAPS is configured with a proper certificate and the binding options set within group policy.

[jschuckert]

I am having this same error and the one new user to the organization (City) is unable to log into Portal. All other users have access as expected. 

Did you ever find a resolution?

Jared

[MattMoore]

We recently came across this in a customers environment. It was actually preventing an upgrade of ArcGIS Portal from 10.8.1 to 11.1 because the ArcGIS Portal post installation configuration steps attempt to test the connection to the configured user store. In this case the Portal had numerous error messages about Portal not being able to connect to Active Directory. The errors tell you exactly what the issue is. ESRI uses the ldaps protocol to communicate with Active Directory. In our case the clients environment was not configured properly to support the ldaps protocol communication with their domain controllers. To get the errors to disappear in Portal this needed to be fixed. They had to do the following...

• Build out an internal Certificate Authority for the internal domain so they could issue trusted certificates to machine on the network.
• Issued a certificate to the two domain controllers. The issued SSL should match each DCs FQDN.
• Installed certificate to the Local Computer Personal Certificates store (certlm.msc) on the respective domain controllers.
• Restarted domain controllers.
• Once the certificates were put in place the errors in Portals log disappeared.