PUT /v3/accounts - 400 - Action cannot be performed

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

We have an RPA process that updates a CSV source using the create-account and put-account API endpoints. The user making an enhancement process is having an issue when calling the PUT endpoint, specifically when the identity PAT being used is the same identity that the account is linked to

Notable that I can do it with my own PAT and the identity being used for this process is able to update other accounts, just not its “own”

We’ve not seen this before… is there some documentation saying this isn’t possible?

PUT /v3/accounts/ec67feeb4dc84a6c8683f277d7cdd2cf

{
    "attributes": {
        "sourceId": "6e0341d6d14945c09d62efdb3153465e",
        "e-mail": "[email protected]",
        "groups": [],
        "IIQDisabled": false
    }
}

Response

{
    "detailCode": "400.1 Bad request content",
    "trackingId": "ad054f878dc64755aa8920a83246f97e",
    "messages": [
        {
            "locale": "en-US",
            "localeOrigin": "DEFAULT",
            "text": "Action cannot be performed on ec67feeb4dc84a6c8683f277d7cdd2cf."
        },
        {
            "locale": "und",
            "localeOrigin": "REQUEST",
            "text": "Action cannot be performed on ec67feeb4dc84a6c8683f277d7cdd2cf."
        }
    ],
    "causes": []
}
2

I can’t find any documentation but I recently noticed that I can not access any drop downs or dot menus on my user account from the interface. Maybe this has always been the case but I wonder if what you are seeing is just this the same behavior being applied to a PAT.

Is it possible to create a “service account” to create the PAT token instead of the user using their own?

Alicia

1 Like
3

Hi @mcheek
Did you verify the scope of the PAT?
I think the PAT may not be authorized to the endpoint…
Thanks, Vasanth

4

Hello @mcheek
As @agutschow mentioned, we cannot perform any operations related to our own Identity which also includes any updation to the accounts like removing or anything. While ensuring this SailPoint has blocked all modification to existing account for its own Identity even via API’s.
And anyway for WF’s/Development purposes its always advised to have a service account to generate PAT’s so that even if a employee leaves it does not hamper any operations as Service Account will not be disabled by your teams.

1 Like
5

Thanks @harshamin9 ,

We are using a service account to perform this action. Since this particular API requires a PAT tied to a user (as opposed to application credentials), we have to use a service account with an identity. Inevitably, you will find there are situations where service accounts with identities will have accounts in some systems, which will result in this issue coming up.

I feel like I’ve said it many times, but the requirement of user context PATs to perform API actions as opposed to application tokens causes issues in many areas, and it’s something that should be addressed. See a similar post below

I have also mentioned how much of a pain it is to generate and manage PATs for service account identities

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.