This article comes from a situation I managed to get my lab environment into when I was not paying proper attention to the configuration changes I was making (doing several things at once never works out well!).  I was testing out Kerberos authentication in vRA 7.5 and managed to lock ALL users out of authenticating into the portal.

The default access policy in vRA controls the authentication methods that are applied as well as the order they are attempted in when a user tries to login to the portal.  If you amend the policy such that the only methods left in the policy are ones that do not work then you will end up in the same situation as me.  When this happens (and if your current session times out like mine did) then you have no way to get back into the portal to reverse your changes.

Thankfully you can amend the access policy via the identity manager API and a REST client (e.g. curl, POSTMAN etc.).  In this example I am using POSTMAN.

The first step is to get an authentication token for vIDM by supplying a valid admin username and password combination as parameters in a vRA “POST” request (note the administrator account cannot be used!).  The URL is:

https://vRA-FQDN/SAAS/t/INSERT_TENANT_NAME/auth/oauthtoken

The parameters are appended to the URL automatically if using POSTMAN.

The body of the response will contain the token which will then be used in all other requests to the vIDM API.  The long “access_token” value should be copied, not including the quotation marks.

The next step is to use the token to get a list of all the access policies within vIDM.  As this is embedded vIDM there should only be a single policy.  The request is a “GET” to the following URL.

https://vRA-FQDN/SAAS/t/INSERT_TENANT_HERE/jersey/manager/api/accessPolicies

Several header key pair values are required in the request:

• Authorization – This should have a value of “HZN” followed by the token (note the space between the two values)
• Content-Type – application/vnd.vmware.horizon.manager.external.identityprovider+json

The body of the response should include a JSON formatted body containing all access policy data like this.  The only piece of information we need from the response is the UUID of the default access policy.

The UUID will be used to submit a second “GET” request, this time with the UUID appended to the same URL as shown below.  The headers are also the same as the previous request.

Once you have the body from this last request you can copy it to a JSON editor and start amending it.  The “chainedAuthMethodsList” attribute will/should contain an array of authentication policies.  The safest way to restore access is to revert the authentication method to local password access by pasting the following over the top of the existing “chainedAuthMethodsList” attribute.  Note that this needs to be done for each rule within the access policy (by default this will be 2 rules, device policy and web policy).

“chainedAuthMethodsList”: [
       {
              “chainedAuthMethods”: [
                     {
                           “authMethodName”: “Password (Local Directory)”,
                           “samlAuthnContext”: “urn:vmware:names:ac:classes:LocalPasswordAuth”,
                           “authScore”: 0,
                           “defaultMethod”: true,
                           “authMethodId”: 3,
                           “authMethodOrder”: 1,
                           “remoteApiAuth”: false,
                           “domainRequired”: true,
                           “_links”: {}
                     }
              ]
       }
],

Once the policy has been amended it can be used as the payload body of a “PUT” request in order to update the policy. To do this the same URL can be used that contains the UUID of the policy however the Content-Type header value needs to be changed.

The Content-Type value should be:

application/vnd.vmware.horizon.manager.accesspolicyset+json

Once the “PUT” has been submitted a status response code of “200 OK” should be received.  At this point the amended policy should now be active, no service restarts are required.

Hopefully this will help you out if you make a mistake in your policy configuration.