How to recover TAS UAA admin permissions
search cancel

How to recover TAS UAA admin permissions

book

Article ID: 297948

calendar_today

Updated On:

Products

VMware Tanzu Application Service for VMs

Issue/Introduction

As part of UAA user management, an operator would sometimes be required to update the UAA admin account permissions using the uaac client. The uaac client accepts any string it is given as the value for the 'authorities' field when updating a client record and will entirely replace the value that is currently saved in the UAA database with the newly entered value. So, as an example, if you run the following command as-is, then you will end up having a UAA admin account that doesn't have the usual admin permissions.
$ uaac client update admin --authorities "EXISTING-PERMISSIONS healthwatch.admin"

This article contains the details of the steps on how to revert and recover the admin permissions.

Environment

Product Version: 2.2

Resolution

Your UAA admin account gets the 'insufficient_scope' error when trying to execute the admin commands.
error response:
{
  "error": "insufficient_scope",
  "error_description": "Insufficient scope for this resource",
  "scope": "uaa.admin clients.read clients.admin zones.uaa.admin"

The output of `uaac context`, when using the admin account, doesn't show all the usual admin scopes (e.g., "clients.read, password.write, clients.secret, clients.write, uaa.admin, scim.write scim.read").
[0]*[admin]
    client_id: admin
    access_token: <redacted>
    token_type: bearer
    expires_in: 43199
    scope: EXISTING-PERMISSIONS healthwatch.admin
The most likely cause is that an operator has updated (via the uaac client) the admin authorities improperly and replaced the standard admin authorities.

This can happen if you follow the instructions in some of the documentation too literally. In the docs, it will in places reference "EXISTING-PERMISSIONS", but the intent is for the user to substitute the actual existing permissions into the command instead of this placeholder value. If you do not make this substitution, that can cause the problem described in this article.

See step #7 of this doc as an example.
This can be recovered by using another UAA client with a 'clients.admin' scope to update the admin client and reinstate its original permissions.

Currently, the clients 'gorouter' and 'cc-service-dashboards' have the 'clients.admin' scope.

The following steps can be used to recover the admin permissions.

1. Retrieve the secret for the 'gorouter' client from Ops Manager->PAS->Credentials->Gorouter Client Credentials.

2. Get a UAA token as the 'gorouter' client. Enter the secret you retrieved from step 1:
$ uaac token client get gorouter

3. Update the 'admin' client by executing the following command:
$ uaac client update admin --authorities "clients.read clients.write clients.secret uaa.admin scim.read scim.write password.write"

4. Then, get a new UAA token as the 'admin' client:
$ uaac token client get admin

5. Your admin client should now have its original permissions back. You can run `uaac context` to verify the scope:
$ uaac context 
[0]*[admin] 
    client_id: admin 
    access_token: <redacted> 
    token_type: bearer 
    expires_in: 43199
    scope: clients.read password.write clients.secret clients.write uaa.admin scim.write scim.read