I have an application that needs to create AD groups and update their memberships via Graph API. I'll be using a service principal to do so.
I'm trying to understand the difference between:
assigning the service principal to an Azure AD role (for example, "User Administrator": https://learn.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task#groups)
adding API permissions to the service principal (for example, Microsoft Graph API's "Group.ReadWrite.All": https://learn.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task#groups)
What are the differences here? Do they both effectively give the same permissions?
A built-in role is just a collection of permissions so your answer can be yes. If you grant the same permissions in as a built-in role then you will get the same effective permissions. The "User Administrator" role has the following permissions:
https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#user-administrator
We created built-in roles to make it easier for users to quickly get role based access control in place. If built-in roles don't meet your needs, you can always create a custom role.
I'm mulling over the same question - which approach is better, MS Graph permissions or built-in roles. I'm leaning towards the built in roles for easier visibility and the potential to assign the permissions to groups.
Unless things have changed very recently you can only create AAD custom roles for a subset of "Application Administrator" permissions - not for any permissions.
Related
Is there any Azure policy can be in place which will restict users so that they Can NOT delete any of the Security groups in Azure? even if they can PIM up below roles:
User Admin
Privileged auth admin
Application admin
Conditional access admin
Privillaged role admin
Identity Governance admin
Security Admin
Thanks.
• For now, no such policy can be applied that prevents security group deletion in Azure. But there is a way through which you can prevent security group deletion through assigned Azure AD roles in Azure. For this purpose, you will have to ensure that you don’t assign Azure AD built-in roles like ‘User Administrator, Privileged authentication administrator, etc.’ directly with the default assigned permissions to these roles to any of the user or a group of users in your Azure AD tenant.
Then, create custom Azure AD roles according to your specific requirement with the required permissions only as described in the documentation link as below: -
https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles
https://learn.microsoft.com/en-us/azure/active-directory/roles/custom-create
• Once the custom required Azure PIM specific roles are created, then assign these PIM roles to the required users or a group of users as you deem correct. But do ensure that ‘microsoft.directory/groups/delete’ and ‘microsoft.directory/accessReviews/definitions.groups/delete’ permissions are not assigned to any of these custom PIM roles created and also bar from assigning the built-in Azure AD roles under Privileged Identity Management to any of the users, as these permissions only give the assigned role/user the rights to delete a security group.
In this way, you can restrict the users of PIM and other custom roles or default roles, maybe for that matter, to prevent deleting any security groups in Azure.
Short answer is no, there is no such built-in policy. You would have to rely on custom RBAC roles instead of the built-in roles.
For example, you want to use the NotAction and add this action to it microsoft.directory/groups/delete.
https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference
You can try to use Azure Resources Lock which will protect your resources from accidental deletion, no matter the user permissions. Check this link for more details about Azure resource locks:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json
I'm relatively new to Azure Active Directory & trying to understand some best practices or guidelines for administering custom roles & permissions for application use.
For instance, I might want to create a Role of "Technician" & they have permissions such as "firmware.upgrade" or "product.view" to be enforced within application & endpoints.
Would "Technician" actually be an Azure AD Group then & I could assign custom roles "firmware.upgrade" & "product.view" to that group? Can it even work that way?
Also, I could consider Application Roles, but "Technician" (and others) would be a role used across several applications. So I wasn't sure if an Application Role makes sense to use.
You're on the right track.
You will start by creating app roles like "firmware.upgrade" and "product.view" in your Azure AD application. Please note that these roles are specific to your Azure AD application only and the logic for what a user with these roles can do will be defined in your application code.
Next you would create an Azure AD groups (e.g. "Technicians", "Users" etc.) and start assigning other users in your Azure AD in these groups.
Then you would assign these groups app roles. For example, you can choose to assign "firmware.upgrade" and "product.view" roles to "Technicians" group while "product.view" role to "Users" group.
When a user authenticates/authorizes against Azure AD for your application, the claims will include all the app roles assigned to them either directly or through group membership. Based on the app roles in the claim, you would then grant access to certain parts of your application to these users.
Please do note that while groups are for entire Azure AD, your application roles are specific to an application only. For each application in your Azure AD, you will need to create new application roles.
I can see the other answer is not but an automated answer.. Anyways Azure Active Directory B2C (Business-to-Consumer) does not have the concept of groups and thus group-based assignments of enterprise applications is not possible.
Instead of using groups, you can use custom attributes to assign roles and permissions to B2C users. Custom attributes are user-specific properties that you can define and store on a user's identity. You can use these attributes to store information such as the user's role or permissions.
You can then use these custom attributes to control access to your applications. For example, you can configure your application to check the value of a custom attribute, such as "role", to determine whether a user has the necessary permissions to access a specific feature or resource.
But you also, you need to handle the management and assignment of these attributes yourself, whereas with groups, Azure AD handles that for you.
Are Azure's RBAC tools and capabilities appropriate for delineating and enforcing app-specific user permissions?
What I've been seeing is that Azure's RBAC capabilities seem to involve managing Azure resources: BLOB services, storage accounts, app services, etc.
But what I don't see are examples of Azure RBAC being used to manage app- (or domain-) specific permissions, like "Allow the user to approve purchasing this widget" or "Allow user to categorize these items as Foo, Bar, or Baz", or "Allow the user to view financial data only from these company divisions".
Am I fundamentally misunderstanding how Azure RBAC works, or what it's used to manage? Can anyone point out examples of Azure role definitions that include permissions like the ones above, or point to documentation of how I might set those up?
I believe you are looking for application specific permissions which can be achieved, by configuring API permissions in apps, registered in AD. Please correct me if my understanding is wrong.
So the difference between API Permissions and Role Assignments is as below:
API Permissions: 2 types.
Delegated permissions are appropriate for client apps that access a web API as the signed-in user, and whose access should be restricted to the permissions you select in the next step.
Delegated permissions are used when authentication is done under user's context and are returned in scope claim of the token.
Application permissions are for service or daemon-type applications that need to access a web API as themselves, without user interaction for sign-in or consent. Unless you've defined application roles for your web API, this option is disabled.
App permissions are used when authentication is done under application (service principal) context and are returned in roles claim. For example, if you have a web application, you can configure it to allow access to the user, if the scope claim contains read, otherwise deny access. Or grant write access to application only when roles claim contains write.
You should configure API Permissions when you would like to return the permissions in the Access token. When application consumes the token, it makes authorization decision on the basis of permissions present in the token.
Role Assignments:
RBAC is the authorization system you use to manage access to Azure resources. When using RBAC, an administrator grants permissions to roles, and not to individual users or groups. The administrator can then assign roles to different users and groups to control who has access to what content and functionality.
Role assignments are used to assign permission to users/service principals on Azure Resources. In this case authorization is done by Azure and not by the end application which happens in case of API permissions.
Please ref the below articles for detailed explanation with examples.
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added
I need to register an application in Azure AD using PowerShell. I plan to use the New-AzADApplication cmdlet. The cmdlet documentation states the following:
Below are the permissions needed to create an application:
Azure Active Directory Graph
Application.ReadWrite.OwnedBy
Microsoft Graph
Directory.AccessAsUser.All
Directory.ReadWrite.All
I've learned that these permissions are scopes, which is a new concept to me and something I don't know how to deal with in Azure. I found this short demo, which shows these scopes can be managed as API permissions from the Azure App registration context. However, that demo shows the scopes being managed after the application has already been created. How can I establish the proper scopes before the application is created?
Or, more generally, how can I ensure that I have the appropriate permissions to execute the New-AzADApplication cmdlet?
The application that needs those permissions is Azure AD PowerShell in this case. If it didn't have a service principal in your AAD tenant yet, you would be asked for consent to those scopes on first login when using the Connect-AzureAD cmdlet.
In my experience, the service principal that it uses already exists in your tenant. So it already has the needed permissions. But what will also matter is your user permissions. Since it uses delegated permissions, it is acting on behalf of your user. In order for it to be able to create the app, it needs to have the necessary scope/delegated permission and your user must be able to create applications.
The cmdlets do also support acting as a service principal/app, in which case application permissions given to the app used to authenticate would apply, not delegated permissions. But that's another case that I don't think you are asking about.
Applications are able to note which permissions they require (both delegated and application) in the app registration portal. This allows use of the /.default scope and the Azure portal's "Grant admin consent" option.
You can follow this process:
1.Go to your application in the Azure portal – App registrations experience, or create an app if you haven't already.
2.Locate the API Permissions section, and within the API permissions
click Add a permission.
3.Select Microsoft Graph from the list of available APIs and then add
the permissions that your app requires.
4.Save the app registration.
Is it possible to assign an application (as an Application or Service Principal) to a group programatically, via the graph client or API? (Including the app user credentials needed to allow access of the members of the group to the app)
I searched everywhere and couldn't find documentation for it.
Thanks
No, 'Applications' in Azure AD are used to segment authorization and settings within Azure AD. It creates a trust between Azure AD and your application. The Application is not a User.
Users are Azure AD entities that have identity and can be authorized to access resources (like an Application). Users can be added to groups. See the below link for the Azure AD graph API documentation:
https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/groups-operations#AddGroupMembers
And the documentation on what a user entity looks like:
https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/entity-and-complex-type-reference#UserEntity
Thanks for the answer emseetea, but we do have a little more than that.
Back to the original question - can you programmatically "assign a group to an application". The answer is yes, using appRoleAssignments on the service principal. The service principal represents an application instance, that typically gets provisioned as part of a consent grant. On this tenant specific app instance (service principal) you can attach tenant specific permissions and policy. Permissions get created as part of consent, but you can also programmatically assign an application role (defined by the application) to a user or group. If no application role is assigned, then you can make a "default" assignment. You can find a little more on this topic here http://blogs.msdn.com/b/aadgraphteam/archive/2014/12/12/announcing-the-new-version-of-graph-api-api-version-1-5.aspx which describes a little about this with some sample REST API calls.
This same operation is also possible through the client library. You can take a look at https://github.com/Azure-Samples/active-directory-dotnet-graphapi-console. Look at the section titled "#region Assign Direct Permission". This shows how to assign an app role to a user. You can do the same thing on a group too. If your app doesn't specify any app roles, set the appRoleAssignment.Id to a zero GUID.
Hope this helps,