I was building a small vCloud Automation Center environment in my lab today to test some automation I’m working on and I stumbled upon a weird vCAC/SSO behavior, basically after the vCAC install was complete I could not properly login into shell-ui-app that is the main webapp entry point for vCAC, I was getting just an endless loading spinner on the browser and nothing else.

Looking at the logs in the vCAC appliance under /var/log/vcac/catalina.out I found a hint on what was wrong:

2014-05-14 14:03:40,090 [tomcat-http--25] [shell-ui] INFO  com.vmware.identity.websso.client.endpoint.SsoRequestSender.getRequestUrl:158 - Producing redirect url
2014-05-14 14:03:40,099 [tomcat-http--25] [shell-ui] INFO  com.vmware.identity.websso.client.endpoint.SsoRequestSender.createRenewable:282 - Added Renewable condition
2014-05-14 14:03:40,100 [tomcat-http--25] [shell-ui] INFO  com.vmware.identity.websso.client.endpoint.SsoRequestSender.createDelegable:290 - Added Delegable condition
2014-05-14 14:03:40,101 [tomcat-http--25] [shell-ui] INFO  com.vmware.identity.websso.client.endpoint.SsoRequestSender.getRequestUrl:245 - Destination URL: https://10.250.0.127:7444/websso/SAML2/SSO/vsphere.local

Looking at the last line, the destination URL for SSO is wrong, as that is an ip that sits in my DHCP pool and is not used by servers I deploy in my lab.

I started wondering how was that possible, then I realized that initially this vCenter was deployed with an ip coming from the DHCP pool and was subsequently moved to a different static IP, that is something that needs to be fixed in SSO, strangely enough, vCenter logins through the very same SSO instance work just fine.

I started digging around in the vCenter Appliance to find references to the old ip, I found that /etc/vmware-identity holds the configuration for SSO (at least for the token part I need), a quick cat revealed the wrong configuration:

vpx:~ # cat /etc/vmware-identity/hostname.txt
10.250.0.127

vpx:~ # cat /etc/vmware-identity/sso.properties
serviceVersion=1.0
hostId=localhost.localdom
ownerId=localhost.localdom@vsphere.local
serviceType.product=com.vmware.cis
serviceType.type=cs.identity
serviceNameResourceKey=sso.serviceNameResourceKey
serviceDescriptionResourceKey=sso.serviceDescriptionResourceKey
serviceGroupResourceKey=sso.serviceGroupResourceKey
serviceGroupInternalId=sso.serviceGroupInternalId
endpoint0.type.id=com.vmware.cis.cs.identity.sso
endpoint0.type.protocol=wsTrust
endpoint0.url=https://10.250.0.127:7444/sts/STSService/vsphere.local
endpoint0.ssltrust0=[...cut...]
endpoint1.type.id=com.vmware.cis.cs.identity.admin
endpoint1.url=https://10.250.0.127:7444/sso-adminserver/sdk/vsphere.local
endpoint1.ssltrust0=[...cut...]
endpoint1.type.protocol=vmomi
endpoint2.type.id=com.vmware.cis.cs.identity.groupcheck
endpoint2.url=https://10.250.0.127:7444/sso-adminserver/sdk/vsphere.local
endpoint2.ssltrust0=[...cut...]
endpoint2.type.protocol=vmomi
endpoint3.type.id=com.vmware.cis.cs.identity.idpprovisioning
endpoint3.url=https://10.250.0.127:7444/sso-adminserver/idp
endpoint3.ssltrust0=[...cut...]
endpoint3.type.protocol=vmomi
endpoint4.type.id=com.vmware.cis.cs.identity.websso
endpoint4.url=https://10.250.0.127:7444/websso/SAML2/Metadata/vsphere.local
endpoint4.ssltrust0=[...cut...]
endpoint4.type.protocol=http
endpoint5.type.id=com.vmware.cis.common.healthstatus
endpoint5.url=https://10.250.0.127:7444/websso/HealthStatus
endpoint5.ssltrust0=[...cut...]
endpoint5.type.protocol=rest

So, in order to fix it, I first stopped vCenter (service vmware-vpxd stop) and proceeded with the changes as follows:

vpx:~ # cat /etc/vmware-identity/hostname.txt
vpx.ad.lab.gosddc.com

vpx:~ # cat /etc/vmware-identity/sso.properties
serviceVersion=1.0
hostId=localhost.localdom
ownerId=localhost.localdom@vsphere.local
serviceType.product=com.vmware.cis
serviceType.type=cs.identity
serviceNameResourceKey=sso.serviceNameResourceKey
serviceDescriptionResourceKey=sso.serviceDescriptionResourceKey
serviceGroupResourceKey=sso.serviceGroupResourceKey
serviceGroupInternalId=sso.serviceGroupInternalId
endpoint0.type.id=com.vmware.cis.cs.identity.sso
endpoint0.type.protocol=wsTrust
endpoint0.url=https://10.250.70.10:7444/sts/STSService/vsphere.local
endpoint0.ssltrust0=[...cut...]
endpoint1.type.id=com.vmware.cis.cs.identity.admin
endpoint1.url=https://10.250.70.10:7444/sso-adminserver/sdk/vsphere.local
endpoint1.ssltrust0=[...cut...]
endpoint1.type.protocol=vmomi
endpoint2.type.id=com.vmware.cis.cs.identity.groupcheck
endpoint2.url=https://10.250.70.10:7444/sso-adminserver/sdk/vsphere.local
endpoint2.ssltrust0=[...cut...]
endpoint2.type.protocol=vmomi
endpoint3.type.id=com.vmware.cis.cs.identity.idpprovisioning
endpoint3.url=https://10.250.70.10:7444/sso-adminserver/idp
endpoint3.ssltrust0=[...cut...]
endpoint3.type.protocol=vmomi
endpoint4.type.id=com.vmware.cis.cs.identity.websso
endpoint4.url=https://10.250.70.10:7444/websso/SAML2/Metadata/vsphere.local
endpoint4.ssltrust0=[...cut...]
endpoint4.type.protocol=http
endpoint5.type.id=com.vmware.cis.common.healthstatus
endpoint5.url=https://10.250.70.10:7444/websso/HealthStatus
endpoint5.ssltrust0=[...cut...]
endpoint5.type.protocol=rest

At this point I gave vCenter a reboot, I could have done a selective restart of services (see KB: 2054085) but given it’s a test environment I didn’t want to bother (I’m lazy).

Unfortunately, the fix wasn’t immediately received by vCAC (probably due to some caching or similar) so I just went to the vCAC Appliance admin page and reconfigured SSO with the same parameters I used during the install, this process takes a while to complete but has picked up the change flawlessly, now I can log into vCAC with no troubles whatsoever.

Hope this will help you too.

Fabio Rapposelli Picture

About the author...

  sddcvirtualizationvmwarevcac

Comments