Posted on

This Method Requires Authentication – Full Version

We were having some issues with one of our VCSA’s and creating or subscribing to Content Libraries. So here is our resolution.

Symptoms:

  • When creating a local Content Library, when clicking finish, it errors with: This Method Requires Authentication
  • When subscribing to another Content Library that has authentication disabled, after copying the json URL into the field and clicking next, it halts the view and states: This Method Requires Authentication
  • When attempting to download Support Bundles from the VAMI at https://<vCenter FQDN>:5480, Downloads timeout and fail

SSH into the VCSA and check the following log files:

/storage/log/vmware/vdcs/cls.log
/storage/log/vmware/vdcs/ovf.log
/storage/log/vmware/vdcs/ts.log

In cls.log, you will be looking for something like this:

cls.log
=========
2016-01-20T14:18:01.773Z | DEBUG    | unset-opId       | tomcat-http--39           | SsoOverRestVerifierUtil        | Trying to verify request signature using following; host:<vCenter FQDN>, port: 443, uri:/cls/resourcebundle
2016-01-20T14:18:01.800Z | ERROR    | unset-opId       | tomcat-http--39           | SamlTokenImpl                  | Signature validation failed
javax.xml.crypto.dsig.XMLSignatureException: the keyselector did not find a validation key
        at org.jcp.xml.dsig.internal.dom.DOMXMLSignature$DOMSignatureValue.validate(Unknown Source)
        at org.jcp.xml.dsig.internal.dom.DOMXMLSignature.validate(Unknown Source)
        at com.vmware.identity.token.impl.SamlTokenImpl.validateSignature(SamlTokenImpl.java:653)
        at com.vmware.identity.token.impl.SamlTokenImpl.validate(SamlTokenImpl.java:535)
        at com.vmware.vim.sso.client.DefaultTokenFactory.parseToken(DefaultTokenFactory.java:46)
        at com.vmware.vim.sso.http.impl.AuthVerifierImpl.validateSamlToken(AuthVerifierImpl.java:77)
        at com.vmware.vim.sso.http.impl.AuthVerifierImpl.verifyToken(AuthVerifierImpl.java:66)
        at com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil.verifySecurityHeaderImpl(SsoOverRestVerifierUtil.java:183)
        at com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil.verifySecurityHeader(SsoOverRestVerifierUtil.java:109)
        com.vmware.vcde.common.services.cm.servlet.SsoAuthenticatedFileStreamServlet.doGet(SsoAuthenticatedFileStreamServlet.java:103)
.
.
.
.
2016-01-20T14:18:01.801Z | ERROR    | unset-opId       | tomcat-http--39           | SsoOverRestVerifierUtil        | Failed to verify request signature using following; host:<vCenter FQDN>, port: 443, uri:/cls/resourcebundle
2016-01-20T14:18:01.801Z | ERROR    | unset-opId       | tomcat-http--39           | SsoAuthenticatedFileStreamServlet | doGet: SSO verification failed for client <vCenter IP Address>
com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil$SsoAuthException: com.vmware.vim.sso.http.AuthException: The SAML token is invalid!
        at com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil.verifySecurityHeaderImpl(SsoOverRestVerifierUtil.java:194)

In ovf.log, you are looking for:

ovf.log
-------
2016-01-20T14:18:01.792Z | DEBUG    | unset-opId       | tomcat-http--23           | SsoOverRestVerifierUtil        | Trying to verify request signature using following; host:<vCenter FQDN>, port: 443, uri:/ovf/resourcebundle
2016-01-20T14:18:01.804Z | ERROR    | unset-opId       | tomcat-http--23           | SamlTokenImpl                  | Signature validation failed
javax.xml.crypto.dsig.XMLSignatureException: the keyselector did not find a validation key
        at org.jcp.xml.dsig.internal.dom.DOMXMLSignature$DOMSignatureValue.validate(Unknown Source)
        at org.jcp.xml.dsig.internal.dom.DOMXMLSignature.validate(Unknown Source)
        at com.vmware.identity.token.impl.SamlTokenImpl.validateSignature(SamlTokenImpl.java:653)
        
        
2016-01-20T14:18:01.805Z | ERROR    | unset-opId       | tomcat-http--23           | SsoOverRestVerifierUtil        | Failed to verify request signature using following; host:<vCenter FQDN>, port: 443, uri:/ovf/resourcebundle
2016-01-20T14:18:01.805Z | ERROR    | unset-opId       | tomcat-http--23           | SsoAuthenticatedFileStreamServlet | doGet: SSO verification failed for client <vCenter IP Address>
com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil$SsoAuthException: com.vmware.vim.sso.http.AuthException: The SAML token is invalid!
        at com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil.verifySecurityHeaderImpl(SsoOverRestVerifierUtil.java:194)
        at com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil.verifySecurityHeader(SsoOverRestVerifierUtil.java:109)
        at com.vmware.vcde.common.services.cm.servlet.SsoAuthenticatedFileStreamServlet.doGet(SsoAuthenticatedFileStreamServlet.java:103)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at com.vmware.vcde.common.services.cm.servlet.DispatcherServlet.service(DispatcherServlet.java:53)

In ts.log, you are looking for:

Ts.log
---------
2016-01-20T14:18:01.792Z | DEBUG    | unset-opId       | tomcat-http--14           | SsoAuthenticatedFileStreamServlet | doGet: Entering (/ts/resourcebundle)
2016-01-20T14:18:01.805Z | ERROR    | unset-opId       | tomcat-http--14           | SamlTokenImpl                  | Signature validation failed
javax.xml.crypto.dsig.XMLSignatureException: the keyselector did not find a validation key
        at org.jcp.xml.dsig.internal.dom.DOMXMLSignature$DOMSignatureValue.validate(Unknown Source)
        at org.jcp.xml.dsig.internal.dom.DOMXMLSignature.validate(Unknown Source)
        at com.vmware.identity.token.impl.SamlTokenImpl.validateSignature(SamlTokenImpl.java:653)
2016-01-20T14:18:01.805Z | ERROR    | unset-opId       | tomcat-http--14           | SsoOverRestVerifierUtil        | Failed to verify request signature using following; host:<vCenter FQDN>, port: 443, uri:/ts/resourcebundle
2016-01-20T14:18:01.806Z | ERROR    | unset-opId       | tomcat-http--14           | SsoAuthenticatedFileStreamServlet | doGet: SSO verification failed for client <vCenter IP Address>
com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil$SsoAuthException: com.vmware.vim.sso.http.AuthException: The SAML token is invalid!
        at com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil.verifySecurityHeaderImpl(SsoOverRestVerifierUtil.java:194)
        at com.vmware.cis.services.common.sso.SsoOverRestVerifierUtil.verifySecurityHeader(SsoOverRestVerifierUtil.java:109)
        at com.vmware.vcde.common.services.cm.servlet.SsoAuthenticatedFileStreamServlet.doGet(SsoAuthenticatedFileStreamServlet.java:103)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

Cause:

According to VMware support, these log entries show no security context for the user. Without that Security content the user cannot perform actions on the content library.

Resolution:

We found the signing cert and its root CA used by SSO from vmware-identity-sts.log and took out the ssoserverSign and the root certificate and added them to the CA to TRUSTED_ROOTS using the below mentioned vets command.

/usr/lib/vmware-vmafd/bin/vecs-cli entry create --store TRUSTED_ROOTS --alias roo51 --cert 51root.crt
/usr/lib/vmware-vmafd/bin/vecs-cli entry create --store TRUSTED_ROOTS --alias roo52 --cert 52root.crt

Then restart all services. Run the following commands. (No there is not a –restart or –reset, use both commands).

service-control --stop --all
service-control --start --all

Thats all for today folks. Hope this helped!

Posted on

Active Directory, Aliases and Hostnames, OH MY!

Before I get into this, I need to set it up.

NOTE: Be prepared to reboot the VCSA a couple times… it takes forever for the web-client to initialize and seriously, that needs to stop VMware. Sub 20 second Web-Client Initialization… NEEDS to be in the next release. I think I speak for everyone when I say that the Web-Client is initializing page is old and needs to die. Anywho. back to the fixing.

We have our active directory domains and our DNS domains. They aren’t the same. We are using alias’s, as support loved to keep saying (I didn’t set it up but sure!) Continue reading “Active Directory, Aliases and Hostnames, OH MY!”

Posted on

Adding vCenters with the similar hostnames to the same Root AD Domain

If you add a Windows Server to a Domain, you have the option of preventing the Domain Controller from changing the servers hostname. The example is if I have server1.acme.com, and I want to add it to my ad.acme.com domain, during the process of registering the server, it will change the servers hostname to server1.ad.acme.com. Not always ideal.

Whats worse is that since the VCSA is based on SUSE Linux, there is no checkbox the uncheck to prevent this during the PSC’s Join Domain functionality. Continue reading “Adding vCenters with the similar hostnames to the same Root AD Domain”

Posted on

Client is not authenticated to VMware Inventory Service after VCSA Upgrade to 6

Had this issue today after upgrading from VCSA 5.5 U3 to 6.6 U1A.

How was the VCSA setup before?

  • DNS servers configured to Prod DNS
  • Time configured to AD servers (automatic when you join the domain from the VAMI)
  • AD configured

Symptoms:

  • Logging into vCenter Server completes successfully with Administrator@vsphere.local
  • AD Users that used to authenticate with vCenter (even Admins) see the following error pop up: “Client is not authenticated to VMware Inventory Service – http://localhost:10080/invsvc”

After looking around, I didn’t see anything that pointed to a specific answer. Also to note, nothing related to vSphere or VCSA 6. A lot of items we found discussed that it was something that was fixed in 5.5 U2. Hmmm.. ok.

Resolution:

  • Since we were using AD for time server because 5.5 U3 VCSA made the AD server the time server, we had no NTP setup in the VAMI. Added the time server and moved on. Oddly for one of our servers, the DNS was missing as well, its odd, but even though it SHOWED the correct DNS servers, when I went to edit the network settings, it was set to automatic. Well that won’t do at all. Set them manually and moved on.

NOTE: Add the vCenter to the root domain if possible, or at least that is what I had to do. If you are adding more than one VCSA to the same domain, with very similar names, read this post as well.

  • Next, I removed any AD Identity sources and then left the domain.
    • If you are unfamiliar with how, first remove the Identity source from Administration > SSO> Configuration > Identity Sources.
    • Then leave the domain from Administration > Deployment > System Configuration > Nodes > {vCenter FQDN} > Manage > Active Directory.
    • Reboot the server after leaving the domain.
  • Once the VCSA comes back up, rejoin the domain:
    • Go back to Administration > Deployment > System Configuration > Nodes > {vCenter FQDN} > Manage > Active Directory, join the domain again.
    • REBOOT! (I know this takes forever, I’m sorry.)
    • Go back to Administration > SSO> Configuration > Identity Sources and add your AD identity source once again.
  • After this is complete, check your permissions and attempt logging in as an AD user.

This fixed it for us, but if you are having worse luck, let me know and I’ll try and work it out with you.