JoneOstebo
Contributor
Contributor

LDAPS on VCENTER 6.7u3 (VCSA)

Hi

I am stuck on adding Open LDAP authentication on my vcenter.

vCenter was freshly installed as 6.7, and have been kept updated.

1. Added certificates to the trusted certificate store in vcenter.

2. Going thru add Open LDAP in vcenter, hit ADD, and just getting an error message:

"Check the network settings and make sure you have network access to the identity source."

Did some debugging, and checked with tcpdump, and I observed that vcenter didn't even try to do DNS lookup, or tried to contact my server.

Did some browser debugging, and got a more explaining error message when debugging the https messages:

"A vCenter Single Sign-On service error occurred"

If I do LDAP instead of LDAPS, it is working perfect. But, my LDAP server don't allow plain text LDAP (security policy).

Right now, I am not able to add LDAP identity source to my vCenter.

Hope someone have experienced similar, and got it solved.

Thanks

Jone

0 Kudos
14 Replies
Lalegre
Virtuoso
Virtuoso

Hey JoneOstebo​,

Do you have port 636 open from the vCenter Server or PSC to the LDAPs server? And also are you being able to resolve whichever host you put on the Domain Controllers to contact?

0 Kudos
JoneOstebo
Contributor
Contributor

I have ports open.

I can resolve ( when using DNS).

I have also verified reverse lookup.

I havr also tested using LDAPS with just IP address, and no difference.

The strange thing is that I NEVER see any packets even leaving the vcenter server (running tcpdump on the VCSA it self).

0 Kudos
Lalegre
Virtuoso
Virtuoso

Hey Jone,

If you connect using SSH into the VM and watch "netstat -puntal | grep 636" does it show the connection?

0 Kudos
commtech1
Contributor
Contributor

1. Please check whether vCenter can be successfully connected or is already connected to the domain.

list available Domain Controllers:

/opt/likewise/bin/lw-get-dc-list Your_domain_full_name

list chosen Domain Controller:

/opt/likewise/bin/lw-get-dc-name Your_domain_full_name

try to join ( if not already connected) the domain via GUI or CLI

Check whether your connected Domain Controller has Global Catalog (GC) option

2. Confirm network settings and connections

cat /etc/resolv.conf

cat /etc/nsswitch.conf

nslookup DomainControler_FQDN

nslookup DomainControler_IP

nslookup Your_domain_full_name

ping DomainControler_FQDN

nc -z -v DomainControler_FQDN 389

nc -z -v DomainControler_FQDN 636

nc -z -v DomainControler_FQDN 3268

nc -z -v DomainControler_FQDN 3269

Share if possible your results without sensitive details (names, IPs)

0 Kudos
JoneOstebo
Contributor
Contributor

It is not showing up here.

root@vcenter [ ~ ]# netstat -puntal | grep 636

tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN      1624/vmdird    

My conclusion is: The vCenter is NEVER trying.

I have proved that by it is not showing up in the netstat table, and it is not showing up when I do TCPDUMP.

TCPDUMP is showing everything going in and out on eth0 of the VCSA.

When doing debugging in the web browser (using Chrome developer tools), I get a different error message than the UI is giving out.

"a vCenter Single Sign-On service error occurred"

To me, it looks like vcenter isn't even creating the LDAP config / applying it / trying.

I tried a fake attempt, just to check.

Created DNS entry of Fake-ldap (including reverse lookup), with IP address 10.10.100.100 (Which is a temporary test computer, in a temp test vlan).

I had two windows open, and tried to ping this IP address:

root@vcenter [ ~ ]# tcpdump -i eth0 host 10.10.100.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

17:25:23.476819 IP localhost.localdom > 10.10.100.100: ICMP echo request, id 7466, seq 1, length 64

17:25:23.477615 IP 10.10.100.100 > localhost.localdom: ICMP echo reply, id 7466, seq 1, length 64

17:25:24.477175 IP localhost.localdom > 10.10.100.100: ICMP echo request, id 7466, seq 2, length 64

17:25:24.484861 IP 10.10.100.100 > localhost.localdom: ICMP echo reply, id 7466, seq 2, length 64

I then try to configure LDAPS to this IP address, and there is NEVER any attempt to even try to reach this IP address.

Anyone else able to try this on yours servers?

Jone

0 Kudos
JoneOstebo
Contributor
Contributor

My vCenter is not connected to an AD domain, and I am trying to reach Open LDAP.

I have connection to another LDAP domain, using LDAP, not LDAPS.

But, for our production environment LDAP is not open, and LDAPS is a requirement.

When I try LDAP to this LDAP server, I can see that vCenter is trying.

When I try LDAPS, there are not one single package going out.

I can ping my LDAP server using FQDN.

I can do reverse lookup to the server using nslookup.

This proves that name resolution is working.

I have found several similar issues with known bugs related to LDAPS in 6.7, but it should be fixed by now.

Maybe it is still a known bug / limitation.

0 Kudos
Lalegre
Virtuoso
Virtuoso

Hey Jone,

Are you configuring using Open LDAP because you are not trying to authenticate with an Active Directory right? Because i was able to configure this but with Active Directory over LDAP and used LDAPs protocol.

0 Kudos
JoneOstebo
Contributor
Contributor

That is correct. This is not Active Directory, but an Open LDAP directory.

Open LDAP is working (using LDAP), but not when I try to use LDAPS.

Jone

0 Kudos
joeflint
Enthusiast
Enthusiast

Hi Jone, were you able to resolve the error message, as i also have same message though using AD

0 Kudos
bmstewart
Contributor
Contributor

JoneOstebojoeflint​ any luck?

I'm just now trying to setup a connection to our AD over LDAP.  I can join the AD domain just fine, and pull users out of that authentication method without issue.

However, if I set up an Identity source using LDAP to point to our domain, I get he same behavior Jone describes.

The UI immediately throws the error, the network inspector shows that it receives an immediate about verifying that you have network access, I can SSH into the VCSA and run an nslookup for the domain, the individual domain controllers, and ping the relevant IPs.

The firewall on the DCs doesn't seem to be the issue - they don't ever see any traffic on the relevant ports to drop.

This happens if I leave it set to use any DC in the domain (which by default tried LDAPS, I believe) or if I manually specify ldap://dc.domain.tld:389 / :636 / :etc.

In short, I don't believe the VCSA is ever actually trying, and I don't know why.

0 Kudos
Tynenmhorn
Contributor
Contributor

JoneOstebo:

I'm facing a similar situation, but I'd like to add some helpful debugging that I've found.

On your vCenter server run:

`tails -f /var/log/vmware/sso/vmware-identity-sts-default.log`.

On your ldap server:
Observe the logs with a command such as `journalctl -fu slapd` if you're running in linux.

That should be able to help you some.

I'm in an odd scenario like you where I can connect through ldap:://some.server.ip:389 , but not through ldaps.

The error that I am receiving on vCenter is the following:

2020-10-23T15:42:09.375Z pool-2-thread-14 vsphere.local  INFO com.vmware.identity.interop.ldap.SslX509EqualityMatchVerificationCallback] Server SSL certificate signature verified.
[2020-10-23T15:42:09.394Z pool-2-thread-14 vsphere.local aafef6f3-b397-495a-80e8-d85c3843fb74 WARN com.vmware.identity.interop.ldap.LdapErrorChecker] Error received by LDAP client: com.vmware.identity.interop.ldap.OpenLdapClientLibrary, error code: -1
[2020-10-23T15:42:09.394Z pool-2-thread-14 vsphere.local  WARN com.vmware.identity.idm.server.ServerUtils] cannot bind connection


On my openLdap server, I can observe a TLS connection being made and then promptly closed (connection lost).

As a side, I can connect through the ldapsearch search command from the vCenter server.

0 Kudos
joeflint
Enthusiast
Enthusiast

Hi, no luck as yet and would be interested if anyone has managed to achieve LDAPs.

I set a new v6.7 test environment i.e. new AD/DNS, vcenter Server and ESXi. All on a flat network with no firewall or NAT. I have no issue with the LDAP configuration but when i attempt to change to  LDAPs have the 'network connection' message.

0 Kudos
joeflint
Enthusiast
Enthusiast

Hi, no luck as yet and would be interested if anyone has managed to achieve LDAPs.

I set a new v6.7 test environment i.e. new AD/DNS, vcenter Server and ESXi. All on a flat network with no firewall or NAT. I have no issue with the LDAP configuration but when i attempt to change to  LDAPs have the 'network connection' message.

I suspect the issue is with the certificate itself. I've tried two methods via export and openSSL and then to add to LDAPs. I'm not not a certificate SME, but installed Certificate Services on the DC which according to documentation auto configures for LDAPs. This is the only grey area, and clarity or documentation on configuring the DC for Certificate Services and then exporting a certifcate for vCenter server lDAPs will help.

For now i've parked this issue, and am considering upgrading to vSphere 7 next month and review again, however, any progress will help.

0 Kudos
jacosta
Enthusiast
Enthusiast

Came across this situation today (10FEB2021).  The short: Vcenter 6.7U3L did not like the SSL certificate that worked just fine on Vcenter 7.0U1.  

Error in GUI:
"Check the network settings and make sure you have network access to the identity source."
 
Error in Browser Developer Tools Console:
angular.js:15635 notificationService::handleError 
message =  Could not parse certificate: java.io.IOException: Illegal footer: -METADATA FROM MY CERTIFICATE <snip>
stack =  undefined

 

Found this article:
https://stackoverflow.com/questions/17543101/java-io-ioexception-illegal-footer-when-importing-certi...

 
Generated "new" certificate files with the below:
echo | openssl s_client -showcerts -connect MYLDAPSERVER.MYDOMAIN.COM:636 > PleaseWork.txt 

 

Edited PleaseWork.txt to only include (inclusive) everything from the first -----BEGIN CERTIFICATE----- to the last -----END CERTIFICATE----- , ensuring five leading and trailing dashes.

Pointed the GUI to PleaseWork.txt instead of my original certificate file.

Worked great on two different Vcenter 6.7U3L systems.

 

0 Kudos