External PSC - VCSA gets Invalid Credentials

[greco827]

I recently deployed an external PSC using the recently-made-public VCSA 6.0 U1 appliance.  Initial deployment of the external PSC went off without a hitch.  No problems whatsoever.  However, when it comes to then deploying the VCSA with an external PSC, I get invalid credentials.

The PSC and VCSA are on the same subnet, and I am deploying from my desktop.  There is no firewall between them, and no east-west traffic control that could be disrupting communication.  I can also telnet to the PSC from my desktop on 443.  No internal certs are being used, just the standard self-signed certs from VMware.

I am NOT using the PSC HA config where an F5 (or any other load balancer) comes into play.  Just a PSC and a vCenter appliance (with the same setup in another datacenter and enhanced linked mode enabled .... if I ever get to that point).

Any ideas?  I believe I have exhausted all Vmkware KB's and googled this thing to death.

I also see these things in the csd log, which correspond with the invalid credentials messages in the vcsa logs :

2015-09-15 15:17:51] [INFO] Request 1151 - [sso: QyUT-UDyA-Okks-RXbt].validate: Received.

[2015-09-15 15:18:12] [ERRO] Request 1151 - [sso: QyUT-UDyA-Okks-RXbt].validate: Error Status ERROR_GET_DOMAIN_NAME: Failed to query SSO domain from '005F2F80': 58

[2015-09-15 15:18:19] [INFO] Request 1153 - [session: session].ping: Received.

[2015-09-15 15:18:49] [INFO] Request 1154 - [session: session].ping: Received.

[2015-09-15 15:19:19] [INFO] Request 1155 - [session: session].ping: Received.

[2015-09-15 15:19:47] [INFO] Request 1157 - [sso: QyUT-UDyA-Okks-RXbt].validate: Received.

[2015-09-15 15:20:08] [ERRO] Request 1157 - [sso: QyUT-UDyA-Okks-RXbt].validate: Error Status ERROR_GET_DOMAIN_NAME: Failed to query SSO domain from '005F2D18': 58

[2015-09-15 15:20:08] [INFO] Request 1158 - [session: session].ping: Received.

[2015-09-15 15:20:19] [INFO] Request 1160 - [session: session].ping: Received.

[2015-09-15 15:20:49] [INFO] Request 1161 - [session: session].ping: Received.

[2015-09-15 15:21:19] [INFO] Request 1162 - [session: session].ping: Received.

[2015-09-15 15:21:49] [INFO] Request 1163 - [session: session].ping: Received.

[2015-09-15 15:22:11] [INFO] Request 1165 - [sso: QyUT-UDyA-Okks-RXbt].validate: Received.

[2015-09-15 15:22:32] [ERRO] Request 1165 - [sso: QyUT-UDyA-Okks-RXbt].validate: Error Status ERROR_GET_DOMAIN_NAME: Failed to query SSO domain from '005F2D70': 58

[2015-09-15 15:22:32] [INFO] Request 1166 - [session: session].ping: Received.

[2015-09-15 15:22:49] [INFO] Request 1168 - [session: session].ping: Received.

[2015-09-15 15:23:19] [INFO] Request 1170 - [session: session].ping: Received.

[2015-09-15 15:23:44] [INFO] Request 1173 - [sso: QyUT-UDyA-Okks-RXbt].validate: Received.

[nimos001]

Have you tried using the IP? I am assuming you have DNS entries setup?

[greco827]

Yes, I have tried the IP.  DNS is working properly, but I used the IP to be sure.  Thanks for the reply though.

[nimos001]

I am actually about to deploy virtual center for my lab environment in the next hour and hopefully I do not run into this issue. I deployed PSC behind an F5 load balancer this morning but hadn't had time to deploy virtual center just yet. I am using the U1 code as well.

EDIT: Maybe you can SSH to the PSC and reset that password as an option?

[greco827]

I have reset the password and actually deployed the PSC multiple times, always with the same end result.  In your case, the F5 brings an additional layer into the mix, and there are lots of articles on things that need to be done.  This is a good KB for that setup: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=211331...

For my situation, I think it is somehow network related.  The PSC sits on the same network as the VCSA will, and the same network as the ESXi hosts for that matter, (just a big management VLAN), and the request to validate against SSO seems to be received, but then denied.  I'm not sure if it is simply unable to respond to the request, or what.  When deploying both the PSC and the VCSA, I am deploying them directly to hosts, not a vCenter (which I also tried with the same result), so I'm not sure if there is something on the host that isn't allowing the authentication.  I need to find out more of what is happening across the network in the background and what those interactions are so that I can maybe pinpoint where the failure is.

[2015-09-15 16:11:25] [INFO] Request 34 - [session: session].ping: Received.

[2015-09-15 16:11:55] [INFO] Request 36 - [session: session].ping: Received.

[2015-09-15 16:12:25] [INFO] Request 38 - [sso: QyUT-UDyA-Okks-RXbt].validate: Received.

[2015-09-15 16:12:46] [ERRO] Request 38 - [sso: QyUT-UDyA-Okks-RXbt].validate: Error Status ERROR_GET_DOMAIN_NAME: Failed to query SSO domain from '00440F18': 58

Might just have to open a case.

[greco827 · Accepted solution]

While this can be caused by a certificate mismatch, in my case it was a problem with the desktop network.  While port 443 was open to both the ESXi host and the External PSC, UDP 123 was not, and while not noted in any log, this appears to have been the problem.  NTP on the PSC itself worked fine.

As a test, I attempted to deploy VCSA w/an embedded PSC.  This deployment also failed citing NTP as an issue.  Changing the setting to sync with the host allowed fro deployment to continue.  If you have a similar problem with invalid credentials, this may be a good test for you as well to make sure UDP 123 is reachable from your desktop.  I'm not sure why it needs to be, but I can only assume that the place from which you are running the installation acts as a communication proxy of sorts.

So in addition to making sure DNS forward and reverse lookup are working properly, check port 443 to the external PSC and target host, and if those things are good, attempt to deploy a VCSA appliance with the embedded PSC using NTP for time sync.  If this fails, you may need to change your deployment location (unless if is easy for you to get this port opened).

I simply built a basic Windows VM on the same subnet as my other management/infra devices, pushed the .iso to a datastore, and mounted it on that VM and ran the install from there.  Went off without a hitch.