Open danybeam opened 4 years ago
@danybeam , could you clarify the user's permission? Or could you create the same user for my test?
If I run
Get-AzureRmRoleAssignment -SignInName daorozco_testuser@rbacclitest.onmicrosoft.com
I get
RoleAssignmentId : /subscriptions/4004a9fd-d58e-48dc-aeb2-4a4aec58606f/resourcegroups/cloud-shell-storage-westus/providers/Microsoft.Authorization/roleAssignments/5878bd47-0579-490a-9319-14bef14fd927
Scope : /subscriptions/4004a9fd-d58e-48dc-aeb2-4a4aec58606f/resourcegroups/cloud-shell-storage-westus
DisplayName : daorozco_testuser
SignInName : daorozco_testuser@rbacclitest.onmicrosoft.com
RoleDefinitionName : Reader
RoleDefinitionId : acdd72a7-3385-48ef-bd42-f606fba81ae7
ObjectId : 11b1042e-d5b6-4f65-b308-d69565f16f1e
ObjectType : User
CanDelegate : False
RoleAssignmentId : /subscriptions/4004a9fd-d58e-48dc-aeb2-4a4aec58606f/resourceGroups/daorozco_bug_repro/providers/Microsoft.Authorization/roleAssignments/299f0cc1-8d11-4d09-8d6a-ac58fa73fc2c
Scope : /subscriptions/4004a9fd-d58e-48dc-aeb2-4a4aec58606f/resourceGroups/daorozco_bug_repro
DisplayName : daorozco_testuser
SignInName : daorozco_testuser@rbacclitest.onmicrosoft.com
RoleDefinitionName : Reader
RoleDefinitionId : acdd72a7-3385-48ef-bd42-f606fba81ae7
ObjectId : 11b1042e-d5b6-4f65-b308-d69565f16f1e
ObjectType : User
CanDelegate : False
With the parameters you provided, New-AzADServicePrincipal will:
Step 1 and step 2 succeeded because by default, all regular users are allowed to create Application objects and their ServicePrincipal objects in Azure AD. (You could also do this in the Azure portal through Azure AD > App registrations). Step 3 failed because you are only "Reader" on the target Azure subscription, so you're not allowed to grant access to it.
A user's authorization in Azure AD (e.g. to register apps) is independent of a user's authorization in an Azure subscription. Get-AzureRmRoleAssignment will only tell you about the user's authorization in Azure subscriptions.
after much examination from our part we noticed that however there's still some issues with the fact that step 3 fails silently If I need to raise another issue I will but this should not happen as the user would have no clue that they still need to assign a role to the SP
Agreed, this should not fail silently.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc
Description
New-AzADServicePrincipal is able to create a new SP even when user has no write permissions (i.e.: Reader role) This bug doesn't seem to be directly reproduceable from portal.azure.com nor through AzureCLI in bash/cmd
Steps to reproduce
it is not subscription or resource group specific
Environment data
this is also not OS nor Platform specific, it's also reproduced in the azure portal cloudshell.
Module versions
Debug output
Error output