BHagenSPI
Enthusiast
Enthusiast

Error when trying to add an identity source

Jump to solution

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

Backstory:

I opened a ticket with vmware support on 1/31/2020 because "something" was logging into 4 out of 6 esxi hosts in my DR cluster, and it was failing. The error is "Cannot login administrator@vsphere.local@(IP of our DR Veeam NAS repository)", and happens every 2 to 3 minutes.

I opened a ticket with Veeam; they can't find the issue. Opened a ticket with vmware; they can't find the issue.

In the meantime, something *else* went wrong on the 20th; my DR cluster (the one getting the failed login attempts) lost all its permissions except for administrator@vsphere.local. Yet the production VCSA has all it's permissions in tact. So if I log in as myself, I *only* see the production datacenter; if I log in as administrator@vsphere.local, I see both production and DR datacenters.

Current Story:

And now, the subject of this post: now when we try to add an identity source, the get the error "Check the network settings and make sure you have network access to the identity source."

BUT: when I putty into both the VCSAs, I can ping all our domain controllers, all the esxi hosts, and the other vcsa. No issues; no dropped packets.

Doesn't matter what version of identity source we try to add (AD, AD over LDAP, LDAP), we get the same error.

  • We've upgraded both VCSAs to the latest (6.7.0.42100), with no changes.
  • Both VCSAs are joined to our domain.
  • The SSO domain is NOT the same name as our domain.

It seems like the answer is going to be soooo simple...but nobody seems to be able to find it.

Any ideas? Or hints?

1 Solution

Accepted Solutions
BHagenSPI
Enthusiast
Enthusiast

Thanks for the reply msripada​! You were on the right track. I spent another 3.5hr on the phone with vmware support yesterday after I posted this. From the production VCSA, they did pings to all our DCs (all tested fine, and we'd done that a few days ago), and then they did nslookup of the IP of each DC. Sure enough, several failed! They then found that the DCs that failed an nslookup from the VCSA didn't have records in our reverse lookup zone in DNS.

So I went thru and manually added entries for each of the DCs that failed nslookup into the in.addr.arpa reverse lookup zone in DNS, and BINGO; we can now add the identity source!

(BTW, adding a manual entry in the reverse lookup zone requires that you input the IP address backwards! So 1.2.3.4 would have to be entered as 4.3.2.1, and then add the FQDN of the server in the next box.)

As for the failed login attempts, this didn't help those at all. I do have a ticket open with Veeam, but we've scoured Veeam, and the server attached to IP that's provided in the error, and there's nothing using administrator@vsphere.local as a login credential. In fact, I can power off that server, and we still get the error. So, we're still searching!

View solution in original post

3 Replies
scott28tt
VMware Employee
VMware Employee

Moderator: Moved to vCenter Server


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
0 Kudos
msripada
Virtuoso
Virtuoso

I opened a ticket with vmware support on 1/31/2020 because "something" was logging into 4 out of 6 esxi hosts in my DR cluster, and it was failing. The error is "Cannot login administrator@vsphere.local@(IP of our DR Veeam NAS repository)", and happens every 2 to 3 minutes.

>> Regarding this, we have seen this when there was a configuration set on Veeam using administrator@vsphere.local or veeamone or something on the veeam machine guest OS which reached out with wrong password leads to this.... VMware maximum can give you the IP as they are unaware of the customization of softwares like veeam, it can happen with other softwares also on that machine but the ip used

>> And now, the subject of this post: now when we try to add an identity source, the get the error "Check the network settings and make sure you have network access to the identity source."

Can you check the /var/lib/likewise/krb5-affinity.conf file and ping and nslookup all domain controllers

dns to ensure the same is returning fine without issue

thanks,

MS

BHagenSPI
Enthusiast
Enthusiast

Thanks for the reply msripada​! You were on the right track. I spent another 3.5hr on the phone with vmware support yesterday after I posted this. From the production VCSA, they did pings to all our DCs (all tested fine, and we'd done that a few days ago), and then they did nslookup of the IP of each DC. Sure enough, several failed! They then found that the DCs that failed an nslookup from the VCSA didn't have records in our reverse lookup zone in DNS.

So I went thru and manually added entries for each of the DCs that failed nslookup into the in.addr.arpa reverse lookup zone in DNS, and BINGO; we can now add the identity source!

(BTW, adding a manual entry in the reverse lookup zone requires that you input the IP address backwards! So 1.2.3.4 would have to be entered as 4.3.2.1, and then add the FQDN of the server in the next box.)

As for the failed login attempts, this didn't help those at all. I do have a ticket open with Veeam, but we've scoured Veeam, and the server attached to IP that's provided in the error, and there's nothing using administrator@vsphere.local as a login credential. In fact, I can power off that server, and we still get the error. So, we're still searching!