LDAPS inexplicably working on 2 DCs, not on 3rd

[gwilson78]

Please suggest a better title, this issue has sent me through the ringer.

We have a site with an MPLS connection down.  The PAs use the domain controller in our datacenter for authentication for both admin, and GP users, which is over the MPLS.  LDAP requests of coures.. fail.

We also have a DC in Azure, which the PA has an IPSEC tunnel attached through the backup broadband connection at the office.  Users logging into computers onsite, eventually have their login sent to Azure, and they authenticate properly.

External users trying to connect to the local VPN, can't authenticate.

I created a new LDAP server profile, and a new authentication protocol.  The only way it will work, is to set the port to 389, and to uncheck the SSL button.

However, the two other LDAP server that are configured , which are setup from the panorama, AND are the same on all 15 of my PAs,  use port 636, with the SSL box checked.  On other PAs, there are no issues with Authentication.

When I use ldp.exe to connect to the ldap servers, oddly enough, they all work with 389 no SSL.  They also all FAIL when trying to connect with 636 and SSL.

Is there some kind of magic allowing the other servers to work?  I of course inherited the network, but I know we don't have a Cert Authority.  So it would seem I haven't met the requirements for using LDAPS. 

What I'm after, is trying to figure out how the main 2 servers are working on port 636, and if legitimate, I'd like to make those changes to the AZURE server.  This way I can add the AZURE server to the list on the LDAP server profile, so i'm covered in the future.  The only certificates configure on the PA, are a Root, Intermediate , and Wildcard certificate ( full chain)

Please let me know if you have any questions.

Thank you!

[gwilson78]

If they are actuall working on LDAPS,  I don't want to step down the security if I don't have to!