We are still on V6.7U3 until our V7U3 licenses come through next month. I know, I know that it is almost at EOL but... managers with tight pockets...
In the mean time, we have been flagged as using Windows Integrated Authentication so I am trying to set up ldaps which I will also use when we get to V7U3. As a preliminary step, I am trying to get ldap working first but keep running into the error.
Check the network settings and make sure you have network access to the identity source.
I believe that vCenter is trying to access our test domain across an unavailable network and that is causing the error.
I had to hide IP addresses with ### as well as our domain name per corporate security requirements.
To answer the usual solutions.
Our VCSA is a member of our test domain.
The SSO account is administrator@vsphere.local
Windows Integrated Authentication has been removed.
ldp.exe on any machine on the domain can connect to either of our test domain DCs so LDP does work.
Our test domain primary DC is connected to 2 networks. These networks are isolated and have no routing between them. The VCSA should only communicate on the Management network. These are the 2 networks.
- Management network - ###.218.133.x/24
- Test network - 192.168.0.x/20 (supernetted) <- To provide DNS services to test equipment.
Our ESXi servers are connected to the same 2 networks as our domain DC. We have multiple VMs that are also attached to both networks.
- Management network - ###.218.133.x/24
- Test network - 192.168.0.x/20 (supernetted)
Our VCSA is only connected to a single network.
- Management network - ###.218.133.x/24
Some of the commands that I have executed to try to diagnose this issue.
cat /var/lib/likewise/krb5-affinity.conf
[realms]
ourdomain.company.net= {
kdc = ###.218.133.18 <- Primary DC
kdc = ###.218.133.19 <- Secondary DC
kdc = 192.168.0.2 <--- vCenter does not have access to this network.
}
I have tried it by removing the 192.168.0.2 address but it gets added back after a reboot.
nslookup ourdomain.company.net
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: ourdomain.company.net
Address: ###.218.133.18 <-- Our test domain primary DC
Name: ourdomain.company.net
Address: ###.218.133.19 <-- Our test domain secondary DC
Name: ourdomain.company.net
Address: 192.168.0.2 <-- No connection exists to this network.
nslookup ###.218.133.18
18.133.218.###.in-addr.arpa name = DC01a.ourdomain.company.net.
nslookup ###.218.133.19
19.133.218.###-addr.arpa name = DC02a.ourdomain.company.net.
Authoritative answers can be found from:
nslookup 192.168.0.2
** server can't find 2.0.168.192.in-addr.arpa: NXDOMAIN
Here is where I believe that the problem might lie...
nc -vz ourdomain.company.net 389
Warning: Inverse name lookup failed for `192.168.0.2'
ourdomain.company.net [###.218.133.18] 389 (ldap) open
How can I go about telling the VCSA to not use the 192.168.0.x/20 supernet?
Is there anything else to check?
Many thanks for any advice.
All of the other nslookup commands are as expected.
nslookup dc01a.ourdomain.company.net
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: dc01a.ourdomain.company.net
Address: ###.218.133.18
Name: dc01a.ourdomain.company.net
Address: 192.168.0.2
nslookup dc02a.ourdomain.company.net
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: dc02a.ourdomain.company.net
Address: ###.218.133.19