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