Many of us dealing with vRA have at least once been stuck in the situation where they are not able to log in due to bad configuration of the access policies or an identity provider not working. The frustration is enormous, because you start thinking about different ways to overcome the nasty error and finally you end up in a thought loop, much in the likes of Paragraph 22. For my fellow fiction lovers this feeling of desperation might be even further intensified as this dead-end case appears very similar to the one from The Trial.
Let’s say we want to use a federation server like ADFS for authenticating your users or even want to attempt the progressive idea of Just-In-Time User Provisioning. To do this we create a third-party identity provider and set a name for the authentication method. Then, we just modify the policies so that the new authentication method is the default one and we forget to specify a failback policy. We save the policy, logout and try to login, but…
Of course, if our fingers were slower than our mind, we would have thought of opening a different session to vRA and try logging in from it, while having the original vRA session still active, but evolution has brought us so far. If we click “Change to a different domain”, we will be presented with the same domain we configured SAML for and will eventually end up with the same error.
Fixing your access policies
The only way out of this situation is to reset the policies the way they were before. This can be achieved with some combination of Linux commands and API requests.
First, we need to authenticate to the management API of vIDM. There is a solution user, embedded in vRA, that you can use as the client in order to communicate with vIDM. Let’s extract its details.
Open an SSH session to the vRA appliance and issue the following commands:
# Getting the clientID and secret (grep -i csp-admin= /etc/vcac/solution-users.properties | \ sed -e "s/csp-admin=//") | tr -d '\n' > client_auth; echo -n ":" >> client_auth; (grep -i csp-admin.secret /etc/vcac/solution-users.properties | \ sed -e "s/csp-admin.secret=//" | xargs -n 1 vcac-config prop-util -d --p) >> client_auth; #Convert the client_auth file contents to a base64 string. base64 client_auth;
Then, use any Rest API Client to fire the following request (don’t forget to substitute the sections in italics with the information about your own environment):
POST https://vRA_HOST_NAME/SAAS/t/YOUR_TENANT/auth/oauthtoken?grant_type=password HEADERS: authorization: Basic BASE64_client_auth #just substitute BASE64_client_auth with the base64 representation of the client_auth file HEADERS: content-type: application/x-www-form-urlencoded BODY: username=TENANT_ADMINISTRATOR&password=YOUR_PASSWORD
This request will give you an access token generated by vIDM. We can use this token to get a list of all policy sets defined in vRA (actually, in vRA there is always one policy set – the default one):
GET https://vRA_HOST_NAME/SAAS/t/YOUR_TENANT/jersey/manager/api/accessPolicies HEADERS: Authorization: HZN GENERATED_TOKEN #Just type in the token that was generated by the authentication request HEADERS: Content-Type: application/vnd.vmware.horizon.manager.external.identityprovider+json
This results in a JSON response that has the id of the default policy set. We need to extract the id of the default policy set and get its individual JSON representation:
The JSON response has an href value under the items node:
Copy the URL and fire the following request:
GET https://vRA_HOST_NAME/THE_URL_YOU_JUST_GRABBED HEADERS: Authorization: HZN GENERATED_TOKEN Content-Type: application/vnd.vmware.horizon.manager.external.identityprovider+json
Now, we have the JSON representation of the default policy set only and not just a list of all sets. We will modify this JSON and provide it back to vIDM. Having a representation of the individual policy set is important as vIDM expects the JSON we provide to have the same structure that it holds currently.
Look for the chainedAuthMethodsList section in the JSON response and then find your chained method that refers to the authentication method that fails. It should look something like this (my failing authentication method is marked in red):
Delete the chainedAuthMethods node alongside its enclosing curly brackets from the JSON representation so that it has only the chainedAuthMethods node representing the failback method. It should look like this:
If you don’t have a failback method, just copy this JSON node from here. It resets the policy, so that only authentication with local credentials is possible (the vsphere.local domain):
{
"chainedAuthMethods": [
{
"_links": {},
"authMethodId": 3,
"authMethodName": "Password (Local Directory)",
"authMethodOrder": 1,
"authScore": 0,
"defaultMethod": true,
"domainRequired": true,
"remoteApiAuth": false,
"samlAuthnContext": "urn:vmware:names:ac:classes:LocalPasswordAuth"
}
]
}
Upload the new policy set configuration:
PUT https://vRA_HOST_NAME/THE_URL_OF_THE_POLICYSET HEADERS: Authorization: HZN GENERATED_TOKEN HEADERS: Content-Type: application/vnd.vmware.horizon.manager.accesspolicyset+json BODY: MODIFIED_JSON_FILE
Enjoy logging into vRA one more time.
