[Bug]: Cannot elevate Azure Directory Roles (Entra ID)

[aaearon]

Bug Description

The CLI currently cannot elevate to Azure Directory Roles (also known as Entra ID roles). When attempting to elevate to a directory role such as 'Global Reader' or 'Security Reader', the elevation fails or the role is not listed in the eligibility response.

This is a significant limitation as many Azure administrative tasks require directory-level permissions that are separate from Azure RBAC (Resource-based Access Control) roles.

Expected Behavior:
Users should be able to discover and elevate to Azure Directory Roles through the CLI, just as they can with subscription-level RBAC roles.

Actual Behavior:
Azure Directory Roles are either not returned in the eligibility list, or elevation requests to directory roles fail.

Command

grant azure
# or
grant azure --role "Global Reader"

Error Output

# Directory roles are not shown in the interactive list
# or
# Error when attempting to elevate to a directory role

Grant Version

Current version (all versions affected)

Operating System

All platforms (Linux, macOS, Windows)

Verbose Output (Recommended)

N/A - This is a feature limitation rather than a runtime error.

Checklist

• I have searched existing issues to ensure this is not a duplicate
• I have redacted any sensitive information (tokens, passwords, emails)

---

Technical Context:

Azure has two separate permission models:

1. Azure RBAC (Resource-based Access Control) - for managing Azure resources (subscriptions, resource groups, VMs, etc.)
2. Azure Directory Roles (Entra ID roles) - for managing the Azure AD/Entra ID tenant itself

The SCA Access API may need to differentiate between these two role types, or there may be a separate API endpoint for directory role elevation.

Suggested Solution:

This should be documented in the README under a 'Known Limitations' or 'Supported Role Types' section until the feature is implemented.

[aaearon]

Additional Context:

The current implementation retrieves eligible targets from the SCA Access API's /api/access/{CSP}/eligibility endpoint and creates elevations via /api/access/elevate.

Based on the functional spec and implementation:

• The tool successfully handles Azure RBAC roles (subscription-level, resource group-level, etc.)
• Azure Directory Roles (Entra ID administrative roles like Global Reader, Security Reader, etc.) use a different permission model

What needs investigation:

1. Does the SCA API eligibility endpoint return directory roles in its response?
2. If yes, are they differentiated from RBAC roles in the response structure?
3. If no, is there a separate API endpoint for directory role eligibility?
4. What is the correct request format for elevating to a directory role vs. an RBAC role?

Related Documentation:

• Functional Spec: sca-cli-functional-design-spec-v2.md section 11 (Azure Elevation Model)
• Implementation: internal/sca/access_service.go (SCA Access API client)
• API Spec: Secure Cloud Access APIs.json (if it contains directory role endpoints)

Documented in:

• README.md now includes a 'Known Limitations' section documenting this issue

[aaearon]

Proof of Concept Output

Using the SCA Access API PoC (poc/), I've confirmed that Azure Directory Roles are returned by the eligibility endpoint but cannot be elevated to.

API Responses

1. Eligibility Endpoint Returns Directory Roles ✓

GET /api/access/AZURE/eligibility
Status: 200

Response includes both RBAC and Directory roles:

{
  "response": [
    {
      "organizationId": "[REDACTED]",
      "workspaceId": "providers/Microsoft.Management/managementGroups/[REDACTED]",
      "workspaceName": "Tenant Root Group",
      "workspaceType": "management_group",
      "roleInfo": {
        "id": "/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
        "name": "User Access Administrator"
      }
    },
    {
      "organizationId": "[REDACTED]",
      "workspaceId": "[REDACTED]",
      "workspaceName": "[REDACTED]",
      "workspaceType": "directory",
      "roleInfo": {
        "id": "62e90394-69f5-4237-9190-012177145e10",
        "name": "Global Administrator"
      }
    }
  ],
  "total": 2
}

Key observation: Directory roles use workspaceType: "directory" and the roleInfo.id is a bare GUID (not an ARM resource path).

2. Management Group Elevation Works ✓

POST /api/access/elevate

Request for management_group role:

{
  "csp": "AZURE",
  "organizationId": "[REDACTED]",
  "targets": [{
    "workspaceId": "providers/Microsoft.Management/managementGroups/[REDACTED]",
    "roleId": "/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9"
  }]
}

Response: 200 OK

{
  "response": {
    "organizationId": "[REDACTED]",
    "csp": "AZURE",
    "results": [{
      "workspaceId": "providers/Microsoft.Management/managementGroups/[REDACTED]",
      "roleId": "/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
      "sessionId": "[REDACTED]"
    }]
  }
}

✅ Success - Management group RBAC role elevation works

3. Directory Role Elevation Fails ❌

Attempted 5 different request formats for the Global Administrator directory role. ALL FAILED:

Attempt 1: Bare roleId (GUID only)

{
  "csp": "AZURE",
  "organizationId": "[REDACTED]",
  "targets": [{
    "workspaceId": "[REDACTED]",
    "roleId": "62e90394-69f5-4237-9190-012177145e10"
  }]
}

Status: 500

{
  "code": "1001",
  "message": "Oops! Something went wrong",
  "description": "Please try again in a few minutes. If that doesn't work, contact CyberArk support."
}

Attempt 2: Use roleName instead

{
  "csp": "AZURE",
  "organizationId": "[REDACTED]",
  "targets": [{
    "workspaceId": "[REDACTED]",
    "roleName": "Global Administrator"
  }]
}

Status: 500

{
  "code": "1001",
  "message": "Oops! Something went wrong"
}

Attempt 3: ARM-style roleId path

{
  "csp": "AZURE",
  "organizationId": "[REDACTED]",
  "targets": [{
    "workspaceId": "[REDACTED]",
    "roleId": "/providers/Microsoft.Authorization/roleDefinitions/62e90394-69f5-4237-9190-012177145e10"
  }]
}

Status: 400

{
  "code": "CA1008",
  "message": "Invalid target(s)",
  "description": "One or more of the requested targets do not represent a valid supported target."
}

Attempt 4: ARM workspaceId + bare roleId

{
  "csp": "AZURE",
  "organizationId": "[REDACTED]",
  "targets": [{
    "workspaceId": "providers/Microsoft.Management/managementGroups/[REDACTED]",
    "roleId": "62e90394-69f5-4237-9190-012177145e10"
  }]
}

Status: 400 - CA1008 Invalid target(s)

Attempt 5: ARM workspaceId + ARM roleId

{
  "csp": "AZURE",
  "organizationId": "[REDACTED]",
  "targets": [{
    "workspaceId": "providers/Microsoft.Management/managementGroups/[REDACTED]",
    "roleId": "/providers/Microsoft.Authorization/roleDefinitions/62e90394-69f5-4237-9190-012177145e10"
  }]
}

Status: 400 - CA1008 Invalid target(s)

---

Conclusion

The SCA Access API cannot elevate to Azure Directory Roles (Entra ID roles).

• ✅ Eligibility endpoint returns directory roles
• ✅ Management group RBAC roles work
• ❌ Directory roles fail with either 500 errors or CA1008 "Invalid target(s)"

This is a backend API limitation, not a CLI issue. Directory role elevation may require:

1. A different API endpoint
2. A different request format not yet discovered
3. Additional permissions/configuration in SCA
4. Backend support that hasn't been implemented yet

The CLI correctly implements the documented API patterns - the API itself does not support directory role elevation.

[aaearon]

Revalidation — 2026-03-25

Bug is still present. Tested with pure curl calls (no SDK/CLI involvement) to rule out any client-side issue.

1. Eligibility returns directory roles (200 OK)

curl -s \
  -H 'Authorization: Bearer <TOKEN>' \
  -H 'X-API-Version: 2.0' \
  -H 'Content-Type: application/json' \
  'https://<TENANT>.sca.cyberark.cloud/api/access/AZURE/eligibility'

{
  "response": [
    {
      "organizationId": "<ORG_ID>",
      "workspaceId": "<ORG_ID>",
      "workspaceName": "CyberIAM Tech Labs",
      "workspaceType": "directory",
      "roleInfo": {
        "id": "62e90394-69f5-4237-9190-012177145e10",
        "name": "Global Administrator"
      }
    },
    {
      "organizationId": "<ORG_ID>",
      "workspaceId": "providers/Microsoft.Management/managementGroups/<ORG_ID>",
      "workspaceName": "Tenant Root Group",
      "workspaceType": "management_group",
      "roleInfo": {
        "id": "/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
        "name": "User Access Administrator"
      }
    }
  ],
  "total": 2
}

2. Directory role elevation with roleId — 500

curl -s -X POST \
  -H 'Authorization: Bearer <TOKEN>' \
  -H 'X-API-Version: 2.0' \
  -H 'Content-Type: application/json' \
  -d '{
    "csp": "AZURE",
    "organizationId": "<ORG_ID>",
    "targets": [{
      "workspaceId": "<ORG_ID>",
      "roleId": "62e90394-69f5-4237-9190-012177145e10"
    }]
  }' \
  'https://<TENANT>.sca.cyberark.cloud/api/access/elevate'

{"code": "1001", "message": "Oops! Something went wrong", "description": "Please try again in a few minutes. If that doesn't work, contact CyberArk support.", "errors": []}

HTTP 500

3. Directory role elevation with roleName — 500

curl -s -X POST \
  -H 'Authorization: Bearer <TOKEN>' \
  -H 'X-API-Version: 2.0' \
  -H 'Content-Type: application/json' \
  -d '{
    "csp": "AZURE",
    "organizationId": "<ORG_ID>",
    "targets": [{
      "workspaceId": "<ORG_ID>",
      "roleName": "Global Administrator"
    }]
  }' \
  'https://<TENANT>.sca.cyberark.cloud/api/access/elevate'

{"code": "1001", "message": "Oops! Something went wrong", "description": "Please try again in a few minutes. If that doesn't work, contact CyberArk support.", "errors": []}

HTTP 500

4. RBAC role elevation (control) — 200 OK

curl -s -X POST \
  -H 'Authorization: Bearer <TOKEN>' \
  -H 'X-API-Version: 2.0' \
  -H 'Content-Type: application/json' \
  -d '{
    "csp": "AZURE",
    "organizationId": "<ORG_ID>",
    "targets": [{
      "workspaceId": "providers/Microsoft.Management/managementGroups/<ORG_ID>",
      "roleId": "/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9"
    }]
  }' \
  'https://<TENANT>.sca.cyberark.cloud/api/access/elevate'

{"response":{"organizationId":"<ORG_ID>","csp":"AZURE","results":[{"workspaceId":"providers/Microsoft.Management/managementGroups/<ORG_ID>","roleId":"/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9","sessionId":"<SESSION_ID>"}]}}

HTTP 200 — elevation succeeds, session created.

Conclusion

The POST /api/access/elevate endpoint returns HTTP 500 for targets with workspaceType: "directory" (Entra ID roles), regardless of whether roleId or roleName is used. RBAC roles work fine with the identical request structure. This is a backend API issue — the SDK and CLI are not involved.

Note: The OpenAPI spec lists DIRECTORY as a valid workspaceType for Azure eligible targets and documents that "a maximum of 3 targets can be provided when requesting access to Azure Entra ID."

[aaearon]

Case opened with CyberArk