This message was deleted.

can you test from a client machine to that dc using ldp.exe w/o issue?

It's the NS IPs that will talk to your LDAP. If you need the snip you need to LB your LDAP on your NS. It could just be that your NS can't access your LDAP.

ok! thx all, for the quick replies! @Jon Bucud: I've not used ldp.exe for this testing purpose before, 389 works from a server on the same vLAN / 636 does not. I'll review the AD setup, as I didn't set them up myself, the same test works fine on my home lab where I've had LDAP 636 to my home VPX pair setup for years. @jvitech: Thank you, I'll go back to my firewall guy to ask him to re-review NSIP to LDAP traffic rules between vLans

Could it be that the LDAP environment is lacking enterprise CA / PKI and therefore the LDAP is only usable via 389?

Thing is 389 fails with the same error

ahhh missed the "I don't want to use insecure 389, but for testing purposes , that gave the same result"

Yep! I'll update my post to mention that, I've tried a server/service group/lb server method to start, then just to the individual remote MS AD DC, the result was the same on 389 / 636

With the LB you could see 636 service up?

Yep! It's an odd one, as everything is green until I run the check credentials test, then I get the not a valid ldap server message

i vaguely remember that there was GUI bug for ldap, but I thought that was resolved?

Don't run the test, it's buggy ... just input the creds and test the authentication

Ok! Will do

yes it's not reliable at all ... a joke.

Working on 389! Was a combination of 3 things: Firewall rules, type-o on username (not password) and LDAPS not being in place, my co-worker is setting that up as we speak

Something we can make happen