Azure / Azure/azure-rest-api-specs
AAD: DiagnosticSettings API does not support bearer auth using a service principal
- Dominant language
- TypeSpec
- Stars
- 3.1k
- Forks
- 5.9k
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 424
Description
Attempting to create an AAD Diagnostic Setting using the `aad/mgmt/2017-04-01/aad` package, and it appears the API does not support authenticating as a service principal. I have assigned the Global Admin directory role, and created a custom IAM role containing the documented permissions, but receive the following error.
**Request**
```http
PUT /providers/microsoft.aadiam/diagnosticSettings/testDiagSetting?api-version=2017-04-01
{
"properties": {
"storageAccountId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myTestRg/providers/Microsoft.Storage/storageAccounts/mytestsa",
"logs": [{
"category": "AuditLogs",
"enabled": true,
"retentionPolicy": {
"enabled": true,
"days": 2
}
}, {
"category": "SignInLogs",
"enabled": true,
"retentionPolicy": {
"enabled": true,
"days": 3
}
}]
}
}
```
**Response**
```
:status: 403
cache-control: no-cache
pragma: no-cache
content-type: application/json; charset=utf-8
expires: -1
x-ms-failure-cause: gateway
x-ms-request-id: 1c7be412-20e5-4799-938a-cb6cd9095ffb
x-ms-correlation-request-id: 7e4db2a3-36b9-182b-af82-3796225f9644
x-ms-routing-request-id: UKWEST:20201008T091959Z:1c7be412-20e5-4799-938a-cb6cd9095ffb
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
date: Thu, 08 Oct 2020 09:19:58 GMT
content-length: 402
{
"error": {
"code": "AuthorizationFailed",
"message": "The client '11111111-1111-1111-1111-111111111111' with object id '11111111-1111-1111-1111-111111111111' does not have authorization to perform action 'microsoft.aadiam/diagnosticSettings/write' over scope '/providers/microsoft.aadiam/diagnosticSettings/testDiagSetting' or the scope is invalid. If access was recently granted, please refresh your credentials."
}
}
```
This despite waiting an appropriate length of time for the role permission to take effect, and ensuring the a new access token is issued.
I came across a blog post documenting the same observation: https://cloud-right.com/2018/12/azure-ad-api-logs-flaws
Contributor guide
Research direction
Start with the aad/mgmt/2017-04-01/aad DiagnosticSettings PUT operation and compare its documented permissions with the service-principal request and 403 response shown here. Review the comment thread and linked blog for prior findings; done means establishing whether bearer authentication is supported and, if so, documenting the required authorization behavior in the API specification.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- api, authentication, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100