Hi there,
I have upgraded my Windows vCenter 5.5 to version 6. I accessed the VC by going to https://vc.domain.com, after upgrading to version 6, it redirects me after clicking on "login to web client" to https://vcenter/websso/SAML2/SSOSSL?RelyingPartyEntityId=id (since vCenter is it's hostname). I have tried numerous things, under which:
* Change sso.properties file to match the correct URI
* Change the content of C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx\vpxd.cfg
* Change the settings from the advanced settings in VMware web client (from the vCenter itself):
config.vpxd.sso.admin.uri
config.vpxd.sso.groupcheck.uri
config.vpxd.sso.sts.uri
But all of these RESET on every vCenter reboot, so the settings are never truly applied.
Am I missing anything?
is is the installation Embedded or External ? are you able to login to the client and access the hosts??
is there any error that you notice ? Please paste the screen shots so that i can have a look at it,
i have upgraded to 6.0 , and this works fine without any issues.
Hi Nithy,
Thanks for your reply.
It's an embedded installation. There are no errors. The vCenter server (which is also a VM within ESXi) has two NICs: LAN and WAN. From the LAN side, everything works fine (since the hostname 'vcenter' can be resolved within LAN). However, when accessing the web client through WAN, it redirects me to https://vcenter when visiting the login page. Screenshots:
First (normal working page):
After clicking on "Log in to vSphere Web Client" it redirects me to the local hostname (which is obviously not working through WAN):
I need to change the URI from https://vcenter to https://vc.domain.com; somewhere...
since it WAN, can it be issue with DNS resolution ? Can you check if the VM has correct fqdn configured with proper IP,
Hi Nithy,
No, the FQDN is not correct of the Windows VM. Hostname: "vCenter" and it part of the workgroup "WORKGROUP" (it isn't part of a domain).
edit: I have tried to change the hostname of the vCenter server, but it still redirects me to "vCenter" (so it doesn't look at the hostname of the VM). It could be at install time, but no longer.
Regards,
Gerwim
I'm having the same exact issue with pretty much the same setup. I just want it to load on one IP, the WAN IP.
Literally the same here.
Upgraded a 5.5 VCSA instance to 6.0.
As I specified a hostname during the upgrade process of 'vcenter', .. post upgrade.. and what I normally do to access the UI.. is specify private IP, https://#.#.#.#:9443/vsphere-client (as of 6.0.. I think I can drop the 9443 now.. and just use straight 443).
I do that.. and I get the same initial splash screen .. 'Click here to launch web client'... yada yada..
After clicking that it redirects to the same https://vcenter/websso/SAML2/SSOSSL?RelyingPartyEntityId=...URL. and fails.
I can only launch web client and login if I add a hosts file entry..
Surely, i'm not being forced to use DNS/hostname.. suddenly.. as of VCSA 6.0 ? 😕
What is your appended DNS suffix? Is it blank?
For Workgroup servers, you can add a suffix manually.
System > Change Settings (computer name) > Change > More > <Primary DNS Suffix>
Mine is blank.
As I don't run DNS in my lab.
Are we saying that by populating a suffix (i.e. some vendor software I just use the ole' .local) it won't do the redirect and I can keep using IP addressing to reach it .. like vCenter 5.5 ?
Michael-
My last entry was meant for Gerwin.
For you, have you tried simply using http://<IPaddress> ? (not 443)
Yes. When I said 443.. I meant I implicitly leave the port off.. knowing https is 443.
This WEBSSO/SAML2/SSOSSL redirect is related to some new changes in the SSO service of vCenter 6.0 perhaps ...
Have other people upgraded to vCenter 6.0, not using DNS, no AD integration, and can still reach their 6.0 vCenter without seeing this redirection based on hostname ?
You can also try this format URL: https://<ip address>:9443/
(just like you said earlier, 9443 is implied and no longer needed but I am curious )
Also, what I was inferring earlier was leaving the 'S' off so it uses port 80. (http)
Https = 443
http = 80
If you use port 443, it will look to verify your cert matches the hostname* with your PSC. (formerly SSO in 5.5)
*Hostname on the VCSA should have been entered as a FQDN even if not in a domain.
If you were using SSO prior to your upgrade, you need to upgrade to a PSC.6.0. (this should have been the first step - I assumed you did this as part of the install guide requirements)
I also found an article that may be more applicable to you than just sending the Install Guide.
Configuring VCSA 6.0 as vSphere Web Client Server for vSphere 5.5 | virtuallyGhetto
I can try adding a suffix on the hostname field in the VCSA's DCUI, (to make it an FQDN) but it doesn't take.
It lets me edit the field.. but by escaping that area of the menu and saving settings.. the hostname field reverts to be null/void.
If I negate the suffix, and just go 'vcenter' instead of 'vcenter.local'.. Then it holds after a management network restart.
Where does one configure the VCSA 6.0 ? I.e. the SSO settings that I had access to in VCSA 5.5.. in 6.0 it is now ?
I'm convinced this is an SSO thing....
Did anyone ever figure out a fix for this? Having the exact same problem and I'm stumped.
Not me... I don't understand why there is so little information on this SSO/SAML redirect online.
The only thing I was going to try is building a new VCSA, rather than upgrade.
And see if the same hostname SSO dependence exists...
Not the case in 5.5, but maybe new in 6.0...
Mind you all...
The requirement I need is no DNS, no AD.
Basic IP addressing only.
5.5 never needed any of this, and I can reach vCenter Web UI on IP only...
Seems to be not the case in 6.0.. and I need a hosts file entry in so that quick redirect is honoured and then web ui loads...
Hi there,
Exact same problem here, trying to access vCenter behind a reverse proxy and it look like the hostname (without FQDN) is hardcoded somewhere in the SSO... Or at least with embedded PSC...
Any hint ?
UPDATE - I deployed a brand new VCSA, and did not have this issue.
Though had this when doing an upgrade..
However .. even with a new install .. it got defined with hostname/DNS details of 'localhost.localdom'. And if these are changed. You break SSO.
Also.. the install guide.. vSphere 6.0 Documentation Center, at step 14 makes a mention that you should not be changing or IP address or DNS details post deployment.
However, this, http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=211201..., instructs how to delete SSO identity source, change hostname, re-create certs, and re-create identity source.
I have this feeling.. all this is intertwined..
I have not tried to iterate through this procedure to change my NEW VCSA's hostname and see if I can keep it from breaking.
CypZ try to iterate through KB, change hostname, re-create identity source and certs. See if you can manage to change the hostname and let SSO allow you in.
Also.. persistently.. i.e. make sure it behaves correctly after a reboot as well.
This KB works btw... http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=211201...
Minus the identity source deletion (this is pertinent to Microsoft AD joined identity sources I believe)..
The certificate manager, cert regeneration process was that was required.
I can now change IP and hostname without breaking anything.
For anyone facing the original ...'/websso/SAML2/SLO/*SSO domain name*?SAMLRequest=####' issue try shelling into VCSA and issuing cert regeneration..
Cancel that.
OVF deployments from vSphere Web Client fail.
vpxd.log show STS still referencing the old cert, before I changed the hostname. Which means certificate manager did not replace all certs with the new VMCA root cert created on the spot....
In summary, if you specify an IP address during wizard build of VCSA, there is no way I've found to change the hostname from 'localhost.localdom'. .....
I don't understand why, it's so hard to change TCP/IP parameters of VCSA .... post build........
I have had different issues depending on the browser. Chrome has been the most reliable for me, and IE 11 doesn't handle the redirect very well. However, if I put in the url in the format https://IPorFQDN/vsphere-client/?csp, WITH the ?csp, I never have an issue. Silly, but worth a shot.