I'm in the process of integrating Tenable Cloud Security (TCS) for a comprehensive vulnerability assessment across our Azure subscriptions, but I've hit a consistent authorization wall during the onboarding. Despite following the official documentation to create an Azure AD application and service principal, TCS fails to authenticate and enumerate resources, citing insufficient permissions.
I've provisioned the service principal with what I believe are the requisite RBAC roles, based on both the Tenable guide and our internal security baselines. The principal is assigned the `Reader` role at the subscription scope, and I've also experimentally tried adding `Security Reader` and even `Contributor` on a test subscription, without success. The error in the TCS console remains generic: "Unable to authenticate with Azure. Please check your credentials and permissions."
My current service principal configuration is as follows:
```json
{
"appId": "*****-*-*-*-************",
"displayName": "tenable-cloud-security-sp",
"credentials": {
"type": "client_secret",
"keyVaultReference": "tenable/azure-creds"
},
"requiredResourceAccess": [
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
"type": "Scope"
}
]
}
]
}
```
The role assignments via Azure CLI were executed as:
```bash
az role assignment create --assignee
--role 'Reader'
--scope /subscriptions/
```
My specific questions for the community are:
* Has anyone successfully onboarded Azure with TCS recently and encountered similar hurdles? Were there any nuanced permissions beyond the documented roles that were required?
* Is the `Directory.Read.All` Microsoft Graph API permission (as shown in the `requiredResourceAccess` block) both necessary and sufficient? Some older threads suggest `User.Read` might also be needed for service principal discovery.
* Could this be related to conditional access policies, multi-tenancy, or the type of Azure subscription (in our case, a Microsoft Partner Network subscription with some inherited management groups)? The error message is unfortunately not granular enough to isolate the layer of failure.
I intend to perform a benchmark of the authentication flow using `az rest` calls to isolate the issue, but wanted to check for known configurations first. Any detailed logs or step-by-step validations from your own deployments would be invaluable.
—chris
Oh, service principal permissions are tricky. Did you check if your app registration API permissions (the "requiredResourceAccess" part) includes Microsoft Graph? I think the Reader role is just for Azure resources, but TCS might need Graph permissions to read the directory first.
Also, double check if the client secret hasn't expired. I made that mistake once and got a similar vague error.
The error is often "Insufficient privileges to complete the operation" or "Access Denied," not generic auth failures. A generic authentication error usually means the principal can't even get a token.
Check the actual API call the tool is making. It's likely trying to hit the Azure Management endpoint (` https://management.azure.com/`), not Graph. Your `requiredResourceAccess` snippet is cut off, but that's the OAuth2 side, not RBAC. Both need to be correct.
Try a manual token acquisition with the same credentials and scopes to isolate it. Use `az account get-access-token` or a simple curl to the login endpoint. If that works, the problem is the tool's configured scope. If it fails, your app registration or secret is wrong.