azure-rest-api-specs
azure-rest-api-specs copied to clipboard
AAD: DiagnosticSettings API does not support bearer auth using a service principal
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
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
See this thread for more details: https://github.com/terraform-providers/terraform-provider-azurerm/pull/8581#issuecomment-705535605
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @adamedx.
Do we have any updates on this? Any way we can access this api with service principal or is there any other api to check for diagnostic settings for Azure AD?
Can we please have an update for this issue? Our end to end automation pipelines for multiple customers need this to work.
Following. Also need an update. Cheers.
Any chance we can get an update here? This is still impacting our ability to automate around AAD. Thanks!
Please provide an update on this, this is preventing us to fully automate a customers environment using ADO as we are needing to authenticate via SP.
Year+ later and this is blocking adoption of Microsoft Sentinel. Since we can't apply the Diagnostic Settings on our customers Azure AD environments to send data to Sentinel, we can't use Sentinel for Azure AD without extra work.
Same behaviour here, using Bicep. We need this to work for our customers too. This is a blocker for using IaC end-to-end, which is best practice.
Also needing this to work since setting custom policies to manage this also doesn't work since this is a tenant-level property.
Hi folks. I was facing this issue too and contacted MS support. It's actually possible to access this API using a service principal or apply a bicep with a service principal. The solution is simple: You have to create a very special role assignment for the service principal.
Prerequisite for performing the role assignment
- Global Admin assigned for your user (or the user you want to perform the role assignment with)
- For the tenant the setting "Access management for Azure resources" is set to "Yes" for your user
You can find this setting with the AAD settings -> Properties Changing this setting requires Global Admin
Performing the role assignment
The role assignment can't be performed from Azure portal. Use az
or powershell instead.
- Find out the Object-ID of the Enterprise Application of your Service principal (Just to point it out: Object-ID not Application-ID. Enterprise Application not App Registration)
- Select appropriate built-in role Custom roles are not supported. Roles I validated:
- Reader is able to read but not change the aadiam
- Contributor is able to read and write the aadiam
Perform the role assignment:
az role assignment create --assignee-principal-type ServicePrincipal --assignee-object-id <OBJECT_ID_ENTERPRISE_APP> --scope "/providers/Microsoft.aadiam" --role <ROLE_ID>
After that the Service Principal will have permissions to access aadiam.
Many thanks, Sebastian. Indeed, this is the solution. For those who like the corresponding powershell cmd:
New-AzRoleAssignment -ObjectId "ObjectIdOfTheServicePrincipal" -Scope "/providers/Microsoft.aadiam" -RoleDefinitionName 'Contributor' -ObjectType 'ServicePrincipal'
Just to note, this permission grant also requires "Access management for Azure resources" to be set to 'Yes'
Azure Active Directory > Properties
This is for both CLI and pwsh cmdlets.
bump
as @Kaloszer said
I came across the problem myself now and was happy to find this issue with a workaround. But I can not believe that the issue itself is still open and not being addressed after 4 years....
Any update?