While playing with VMware Single Sign On (SSO) SDK, I got into an exception indicating that the request had expired.
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Request has expired at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) at $Proxy40.issue(Unknown Source) at com.vmware.sso.client.samples.AcquireHoKTokenByUserCredentialSample.getToken(AcquireHoKTokenByUserCredentialSample.java:233) at com.vmware.sso.client.samples.AcquireHoKTokenByUserCredentialSample.main(AcquireHoKTokenByUserCredentialSample.java:285)
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
Initially I thought it might be caused by timestamps in the arguments sent to SSO server. But further investigation showed that the time on my vCenter appliance server had run 3 hours faster than normal, so whatever request I had submitted from my desktop (whose time is up to the date) was “thought” to be submitted 3 hours ago. No wonder the request was rejected as expired. I think there is an allowance of a few minutes and 3 hours was just too big to ignore.
Once the issue was isolated, the solution should be simple – sync up the clock with NTP. It turned out that is not quite as easy as it should be.
# yast2 ntp-client add server=time.nist.gov Error: Cannot update the dynamic configuration policy. # yast2 ntp-client enable
These two commands did not actually work with error as shown above. It should not be an issue with the permission as they were run as root user.
The last command listed in the page worked just fine. The second command showed the updated timestamp.
# sntp –P no –r time.nist.org # date
After a bit Web searching, I got this blog whose author had done good research and found it’s a bug in SUSE (vCenter appliance is based SUSE Linux). The workaround given there is to edit the /etc/ntp.conf and add the following line and restart with “rcntp start” command.
server pool.ntp.org dynamic
After changing this, I haven’t gone back and check if it works. I guess it’s not easy for the time to shift big enough to be noticed or fail my test with SSO in any short time.