OCI REST API call to user management fails with 'NotAuthorized' error despite admin role

Cloud Platforms Oracle Cloud
, , , , , , , ,
1

I’m encountering a frustrating issue when trying to provision users via the OCI IAM REST API. The call consistently returns a ‘NotAuthorizedOrNotFound’ error even though my user has administrator privileges in the tenancy.

The request is being made to create a user in a specific compartment, and I’ve verified the IAM policy syntax allows user management operations. However, I’m wondering if there’s something specific about REST API header requirements I’m missing, or if the issue relates to compartment versus tenancy scope for user operations.


POST /20160918/users/
Authorization: Bearer {token}
Compartment-Id: ocid1.compartment.oc1..xxx

This is blocking our automated user provisioning workflow. Has anyone dealt with similar authorization issues when calling the IAM API? What am I overlooking here?

2

Great that you got it working! Let me provide a comprehensive solution addressing all the key aspects:

IAM Policy Syntax: For user management operations, your policy must be at tenancy scope:


Allow group UserAdministrators to manage users in tenancy
Allow group UserAdministrators to manage groups in tenancy

Compartment-level policies won’t work because users and groups are tenancy-scoped resources in OCI.

REST API Header Requirements: The critical issue was authentication method. Instance principals cannot perform sensitive IAM operations like user/group management. You must use API key-based authentication with proper request signing:


POST /20160918/users/
date: Thu, 18 Mar 2025 09:15:00 GMT
host: identity.us-ashburn-1.oraclecloud.com
(request-target): post /20160918/users/
Authorization: Signature headers="..."

Compartment vs Tenancy Scope: This is crucial - users are ALWAYS created at tenancy level. Never include a Compartment-Id header in user creation requests. The correct endpoint is simply /20160918/users/ with the request body containing:

{
  "compartmentId": "<tenancy-ocid>",
  "name": "username",
  "description": "User description"
}

Note the compartmentId in the body must be your tenancy OCID, not a child compartment.

Implementation Steps:

  1. Create a service user in your tenancy for automation
  2. Generate API signing keys for that user
  3. Add the user to a group with ‘manage users in tenancy’ policy
  4. Configure your automation to use API key authentication (not instance principal)
  5. Ensure all required headers are included in signed requests
  6. Use tenancy OCID as the compartmentId in request payload

The ‘NotAuthorizedOrNotFound’ error you saw is OCI’s way of preventing information disclosure - it doesn’t reveal whether the resource exists or you lack permissions. In your case, it was the authentication method limitation. Instance principals are designed for resource management, not IAM administration.

3

Ah, instance principal authentication! That’s likely your problem. Instance principals have limited IAM capabilities by design. Even with policies granting ‘manage users’, instance principals typically can’t perform sensitive IAM operations like user creation. This is a security boundary in OCI. You’ll need to use user principal authentication (with API signing keys) for user management operations. Instance principals work great for most resource operations but IAM user/group management requires actual user credentials.

4

Thanks for the quick responses. I removed the Compartment-Id header but still getting the same error. I’ve verified the policy exists: ‘Allow group CloudAdmins to manage users in tenancy’. My user is definitely in that group. Could this be related to the API authentication method? I’m using instance principal authentication from a compute instance. Does that change anything for IAM operations?

5

I’ve seen this before. The compartment scope might be your issue. User creation in OCI IAM operates at the tenancy level, not compartment level. You can’t actually create users in a specific compartment - they’re always created at the root tenancy level. The Compartment-Id header in your request is likely causing the API to reject the call. Try removing that header and see if it works.

6

Mike is on the right track. Also check your policy statement syntax carefully. For user management via API, you need explicit ‘manage users’ permission at the tenancy level. A policy like ‘Allow group Administrators to manage users in tenancy’ is required. Compartment-level policies won’t work for user creation operations since users are tenancy-scoped resources.

7

I ran into exactly this scenario last month. What worked for me was switching to API key-based authentication for the user provisioning workflow. We created a dedicated service user with API keys specifically for this automation. Make sure that service user is in a group with the proper tenancy-level IAM policies. Also, double-check your request headers include the proper signing information - date, host, and request-target headers are all required for proper API authentication.

8

That makes complete sense now. Switching to API key authentication resolved it immediately. For anyone else hitting this, here’s what I learned.