Trying to add new Ldap Server. Network Connection Timed Out.

[Mike Zuschek]

I feel like I'm taking crazy pills here. I feel like adding a new Active Directory GC server shouldn't be this hard.

* i am currently using a windows 2008 r2 Active Directory connection over port 389
* i want to retire the 2008 r2 server and add my windows 2016 Active Directory GC server over literally any port that will work. i have tried 389, 636, 3268, 3269
* i get the same error everytime when I click "test connection":
     "Failed to connect to LDAP server. Network connection timed out. Check the hostname used for the source. DDS error code: 800404 Additional information: Failure connecting to data source, network connection timed out:"


* I have tried IP address, common name, and FQDN. and I always get that error.
* I can open up utilities and ping the IP and FQDN.
* I have tried turning the firewall completely off.
* both domain controllers are on the same VLAN

I don't know what else to try.
  "Please help me SMG gurus you are my only hope"

[alexander-smg]

Where’s the pic?

[Mike Zuschek]

[Mike Zuschek]

[Thomas Anderson]

You are correct:  it shouldn't be this hard, so I'm hoping it is something simple.
1.  From within the admin cli on the SMG control center use ping to demonstrate connectivity.  (I know you said you can ping it, but humor me)
  a.  Once using the IP address.
b.  Once using the DNS name.
   The important part is that you do this from within the admin cli of the SMG instance that is trying to get to your LDAP source.

IF all that works out, next verify in your AD instance if it is configured to accept LDAP (i.e. clear text) traffic.  Earlier this year there was a patch/update to AD to disable LDAP.  It's OK, if it is disabled, but you should know that, with that disabled, port 389 is out of the equation.

2.  Assuming you CAN still use LDAP/port 389, again, from within the admin cli, use the "ldapsearch" command to attempt a simple bind to your AD server.  Make sure you are using the SAME bind credentials and search base as you entered into the SMG GUI.  The SMG does, more or less, the same thing behind the scenes when you run the "test query" from the GUI, but this way you can look at it first hand.
I don't know if the version that ships with SMG has debugging enabled, but you can try using the "-d" option to get more verbose output.
This should make it clear what is happening.

[Mike Zuschek]

* ping worked in CLI with both IP and DNS FQDN.
* ran telnet from my desktop to ports 389, 636, 3268, 3269  then used netstat -an | findstr 172.16.5.254 to get connection established for each port
* ran ldapsearch with -d 167 (which is all logging enabled) pictured below

I am convinced it has something to do with that update/patch on my AD environment. Do you have anymore info? If it was the one about LDAP signing, i turned it off in GPO to see if it would work but still no connection success.

[Thomas Anderson]

"I am convinced it has something to do with that update/patch on my AD environment."
Yep, sure seems that way.  The good news is that you have "proven" connectivity, so you know nobody has borked your networking out from under you.
I'm no MIcro$oft expert, I just seem to recall there were 3 things that patch/update did:  1.  Disable LDAP, 2. Introduce "channel binding", and 3. Introduce/enable the LDAP signing stuff.
Refs I found are:  https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-ef185fb8-00f7-167d-744c-f299a66fc00a and https://pleasantsolutions.com/info/pleasant-password-server/i-ldap-and-ad/secure-ldap-is-mandatory-for-active-directory

The interesting thing in the second reference is that it says LDAP (389) will fail and be logged on the AD side:
"LdapErr: DSID-0C090202 - "The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection"

The only other thing I can suggest is to try ldapsearch again, but this time tell it to use LDAPS instead of LDAP, i.e. 
ldapsearch -H LDAPS://my.server -D<binddn> etc, etc.  
and see if that gets you any further along.

[Thomas Anderson]

PS:  errno 110 is TCP timeout

[Sulman Mushtaq Mushtaq Hussain]

did you get it fixed?

------------------------------
Symantec Enthusiast
------------------------------

[alexander-smg]

My ldap works always after any patching in the universe

[Sulman Mushtaq Mushtaq Hussain]

Alex when is 10.8 coming and new features for SMG ?

------------------------------
Symantec Enthusiast
------------------------------

[alexander-smg]

It’s not 10.7.5 is coming out first.

[Sulman Mushtaq Mushtaq Hussain]

when is 10.7.5 coming? does it have new features?

------------------------------
Symantec Enthusiast
------------------------------

[alexander-smg]

1year

[Mike Zuschek]

No, unfortunately I have been unable to resolve this is. Just to cement that it's something with my new domain controllers I was able to connect and test instantly with another 2008 R2 domain controller with the same BIND credentials and over port 389.

I am currently trying to figure out how to ensure my new Server 2016 Domain controllers have LDAPS configured with SSL certs.

[PINGMING CHEN]

Hello Mike :

1. SSH login SMG as user "support"
try below cli & see if return ok  ,
If you could not  reach the destination host/port .,it should be return other error message .
TEST LDAP port 389 :ldapsearch -x -h LDAPhostIP -p 389 -D "username" -W -b "dc=baseDNdomain,dc=com" cn
TEST LDAPS port 636 :openssl s_client -connect HOST:PORT







good luck ..