Resource Access Management:Troubleshoot access denied errors

Console access

Most access denied error pop-ups in the console provide additional error details in addition to the error cause.

You can follow these steps to identify the specific cause of the access denied error and the corresponding resolution.

1. Identify the operator.

   Auth subject provides details about the operator identity as follows:

   • Identity Type: The type of the operator identity. This can be a RAM user, a RAM role, or a federated SSO identity.

   • Identity Information: The identity identifier. A RAM user provides a UID. A RAM role provides the role name and role session name, for example, RoleName:RoleSessionName. A federated SSO identity provides the identity provider type and identity provider name, for example, saml-provider/AzureAD.

   • Account ID: The UID of the Alibaba Cloud account to which the current identity belongs.

2. Identify the missing permission for the operation.

   Action identifies the specific action that caused the access denied error. You can use this action to troubleshoot or grant the required permission.

3. Identify the policy type that affects the permission.

   Policy Type identifies the policy type that caused the access denied error. Policy types include control policies, session policies, role trust policies, account-level identity-based policies, and resource-group-level identity-based policies. For more information, see How RAM evaluates policies.

   The policy type determines how you adjust the policy:

   • If the operation is denied by a control policy (ControlPolicy), contact the management account of the enterprise resource directory to grant the permission. A control policy defines the permission boundary for member access in a resource directory and takes precedence over permission decisions within an account.

   • If the operation is denied by a session policy (SessionPolicy), contact the account administrator to check the session policy attached to the AssumeRole API operation.

   • If the operation is denied by a role trust policy (AssumeRolePolicy), contact the account administrator to check the trust policy of the assumed RAM role.

   • If the operation is denied by an identity-based policy (AccountLevelIdentityBasedPolicy or ResourceGroupLevelIdentityBasedPolicy), contact the account administrator to check the access policies granted to the operator identity.

4. Determine whether the access denied error results from an implicit deny or an explicit deny.

   • Implicit deny: The error cause indicates that the current operation is not authorized, and Denied Type indicates Insufficient permissions. In this case, the account administrator must grant the permission by adding the Action to an Allow statement.

   • Explicit deny: The error cause indicates that the current operation is explicitly denied, and Denied Type indicates Explicit deny. In this case, the account administrator must check the granted permissions and whether a Deny statement includes the Action.

     Note

     If the policy type is a control policy, an explicit deny is also returned when the authorization action is not included in an Allow statement.

In addition, for products that support permission diagnosis, you can click Troubleshooting in the error pop-up to view the cause and solution directly.

The Solutions area of the permission diagnosis pop-up recommends applicable system policies, such as AliyunRAMFullAccess and AliyunRAMReadOnlyAccess, and provides quick actions such as View Authorization, Create Policy, and Add permission.

The permission diagnosis feature is available only for products that support RAM authorization. For products that do not support RAM authorization, permission diagnosis cannot provide troubleshooting results.

Permission diagnosis is a post-event diagnostic tool. You must first make an API call and trigger a denial, and then use the diagnostic ciphertext (EncodedDiagnosticMessage) or RequestID to trace the reason for the denial. Both values come from the response of the denied API call. Permission diagnosis does not currently support simulating or verifying the final effective permissions of a RAM identity in a resource group without a real call.

OpenAPI calls

When you call an OpenAPI operation directly by using an Alibaba Cloud SDK, the CLI, or the OpenAPI Developer Portal, the error response provides error details. The following is an error response returned while debugging in the OpenAPI Developer Portal.

{
  "RequestId": "1090E608-D26F-5A08-BAE3-80D350E9FE20",
  "HostId": "ram.aliyuncs.com",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. Resource: acs:ram:*:xxx:user/* Action: ram:ListUsers",
  "Recommend": "https://next.api.alibabacloud.com/troubleshoot?q=NoPermission&product=Ram",
  "AccessDeniedDetail": {
    "PolicyType": "AccountLevelIdentityBasedPolicy",
    "AuthPrincipalOwnerId": "xxx",
    "EncodedDiagnosticMessage": "AQIBIAAAAMDAbkn...jHF4TLvjT8hp17I0RFKObkV4=",
    "AuthPrincipalType": "SubUser",
    "AuthPrincipalDisplayName": "xxx",
    "NoPermissionType": "ExplicitDeny",
    "AuthAction": "ram:ListUsers"
  }
}

The AccessDeniedDetail field in the error response provides the details of the access denied error. You can follow these steps to identify the specific cause and the corresponding resolution.

1. Identify the operator.

   • AuthPrincipalType: The type of the operator identity. SubUser represents a RAM user, AssumedRoleUser represents a RAM role, and Federated represents a federated SSO identity.

   • AuthPrincipalDisplayName: The identity identifier. A RAM user provides a UID. A RAM role provides the role name and role session name, for example, RoleName:RoleSessionName. A federated SSO identity provides the identity provider type and identity provider name, for example, saml-provider/AzureAD.

   • AuthPrincipalOwnerId: The UID of the Alibaba Cloud account to which the current identity belongs.

2. Identify the missing permission for the operation.

   AuthAction identifies the specific action that caused the access denied error. You can use this action to troubleshoot or grant the required permission.

3. Identify the policy type that affects the permission.

   PolicyType identifies the policy type that caused the access denied error. Policy types include control policies, session policies, role trust policies, account-level identity-based policies, and resource-group-level identity-based policies. For more information, see How RAM evaluates policies.

   The policy type determines how you adjust the policy:

   • If the operation is denied by a control policy (ControlPolicy), contact the management account of the enterprise resource directory to grant the permission. A control policy defines the permission boundary for member access in a resource directory and takes precedence over permission decisions within an account.

   • If the operation is denied by a session policy (SessionPolicy), contact the account administrator to check the session policy attached to the AssumeRole API operation.

   • If the operation is denied by a role trust policy (AssumeRolePolicy), contact the account administrator to check the trust policy of the assumed RAM role.

   • If the operation is denied by an identity-based policy (AccountLevelIdentityBasedPolicy or ResourceGroupLevelIdentityBasedPolicy), contact the account administrator to check the access policies granted to the operator identity.

4. Determine whether the access denied error results from an implicit deny or an explicit deny.

   • Implicit deny: NoPermissionType indicates ImplicitDeny. In this case, the account administrator must grant the permission by adding the AuthAction to an Allow statement.

   • Explicit deny: NoPermissionType indicates ExplicitDeny. In this case, the account administrator must check the granted permissions and whether a Deny statement includes the AuthAction.

     Note

     If the policy type is a control policy, an explicit deny is also returned when the authorization action is not included in an Allow statement.

In addition, for products that support permission diagnosis, you can provide the full value of EncodedDiagnosticMessage to the account administrator. The account administrator can visit the RAM permission diagnosis page to investigate the cause. The account administrator must have the ram:DecodeDiagnosticMessage permission.

If the OpenAPI call returns a Forbidden.RAM error, verify whether the target product API supports RAM authorization. Some product APIs do not support RAM authorization and cannot be called by a RAM identity.

Common scenario: Grant cloud product permissions to a RAM user

When a RAM user operates a cloud product, such as ECS, OSS, or RDS, the console may display Permission denied or an OpenAPI call may return a Forbidden.RAM error. This usually occurs because the RAM user has not been granted the permissions required to operate the cloud product. Grant permissions to the RAM user by performing the following steps:

1. Log on to the Resource Access Management (RAM) console by using an Alibaba Cloud account.

2. In the left-side navigation pane, choose Identities > Users.

3. In the user list, find the target RAM user and click the user's logon name.

4. Click the Permissions tab, and then click Grant Permission.

5. In the policy search box, enter the name of the target cloud product, such as ECS, select the corresponding system policy, and confirm the authorization.

   The following table lists common cloud products and their system policies:

   Cloud product	Full access policy	Read-only access policy
   Elastic Compute Service (ECS)	AliyunECSFullAccess	AliyunECSReadOnlyAccess
   Object Storage Service (OSS)	AliyunOSSFullAccess	AliyunOSSReadOnlyAccess
   ApsaraDB RDS	AliyunRDSFullAccess	AliyunRDSReadOnlyAccess
   Virtual Private Cloud (VPC)	AliyunVPCFullAccess	AliyunVPCReadOnlyAccess
   Server Load Balancer (SLB)	AliyunSLBFullAccess	AliyunSLBReadOnlyAccess

   For more information about system policies, see Manage RAM user permissions.

   Some cloud products do not support RAM authorization. The preceding system policy table applies only to products that support RAM authorization. If an access denied error persists after you grant permissions, check the documentation for the corresponding product to confirm whether it supports RAM authorization.

Common scenario: Insufficient permissions when exporting the instance list in the ECS console

A RAM user has been granted the ReadOnlyAccess system policy, but an access denied error still appears after the user clicks Export Instance List in the ECS console, or a User.NoPermission error is returned. In the error details, the Authorization action is oos:StartExecution, and the Permission decision is Insufficient permissions.

The Export Instance List feature in the ECS console runs an export task asynchronously through CloudOps Orchestration Service (OOS). This action requires the oos:StartExecution and oos:ListExecutions permissions. ReadOnlyAccess includes only read-only query permissions for cloud product resources and does not include CloudOps Orchestration Service execution permissions. Therefore, a RAM user granted only read-only permissions cannot trigger the export.

Attach the AliyunOOSFullAccess system policy to the RAM user, or create a custom policy that grants both oos:StartExecution and oos:ListExecutions permissions. Then export the instance list again.

When you troubleshoot an access denied error, also verify whether the operation involves a cross-product dependency. Some console operations call APIs from other cloud products, and you cannot infer these dependencies from the product name at the operation entry point. Use the Authorization action in the error details, for example, oos:StartExecution, to determine the permission that is actually missing.

HTTP 401 authentication failures

If you encounter an HTTP 401 error (for example, InvalidAccessKeyId.NotFound) while calling an API or logging on to the console, your identity cannot be authenticated. Follow these steps to troubleshoot:

• Check the validity of the AccessKey.

  Log on to the Resource Access Management (RAM) console and view the AccessKey list. If the AccessKey has been deleted, create a new AccessKey.

• Check the status of the RAM user.

  Check the RAM user status and ensure that console logon or the corresponding AccessKey is enabled.

• Check the validity period of the Security Token Service (STS) token.

  Check whether the STS token has expired. An expired credential causes authentication failures. Call the AssumeRole operation again to obtain a new STS token.