Our use case is this: our application needs to access the Azure AD of customer organizations to:
Authenticate users
Sync users' profile data to our app when it changes on AD
Read and subscribe to booking changes in meeting rooms
Our app therefore needs the User.Read.All permission to read profiles of users, but also Calendar.Read.All but the latter must be scoped to a specific group (so as the protect the privacy of actual users). According to this article, a tenant administrator can restrict access of an application to a specific group, but I don't see any way to do this for a single permission, so it would restrict all permissions of an enterprise app to this group. Am I missing something or is this simply impossible and I would need to use multiple service accounts for this purpose?
Currently we can not restric the specific application permission to access a specific group. But we can scope application permissions to specific Exchange Online mailboxes.
Administrators can use ApplicationAccessPolicy cmdlets to control mailbox access of an app that has been granted any of the following application permissions:
Mail.Read
Mail.ReadBasic
Mail.ReadBasic.All
Mail.ReadWrite
Mail.Send
MailboxSettings.Read
MailboxSettings.ReadWrite
Calendars.Read
Calendars.ReadWrite
Contacts.Read
Contacts.ReadWrite
So if you have both User.Read.All and Calendar.Read, the ApplicationAccessPolicy will only work for Calendar.Read permission. The ApplicationAccessPolicy are specific to Exchange Online resources and do not apply to other Microsoft Graph workloads.
Related
We are trying to get list of users from a particular group in Azure Active Directory.
Steps tried:
Created new app registration
Created client secrets
Gave permissions for Graph API (application permissions) with admin consent.
Then we are getting all the users from all the groups.
Is there any way to restrict the app to only be able to return a specific group's users?
For application permissions, the effective permissions of your app are the full level of privileges implied by the permission. For example, an app that has the User.ReadWrite.All application permission can update the profile of every user in the organization, see here.
You could get the users in particular group with List members API, but the application still has the permissions for all groups.
GET https://graph.microsoft.com/v1.0/groups/{group-id}/members
So far, it's only supported to control mailbox access of an app with ApplicationAccessPolicy.
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 was reading about AAD privilege escalation in one of the article where the author states that "if you compromise an Application Administrator account or the on-premise Sync Account you can read and modify directory settings, group memberships, user accounts, SharePoint sites and OneDrive files. This is done by assigning credentials to an existing service principal with these permissions and then impersonating these applications"
my questions are?
1.how can i find what privilege my app admin account has and how it is different from the permissions
that "application " has.
2. what does assigning credentials to a service principal means?
As mentioned in Carl's link,
The Application Administrator role allows users to create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to consent to delegated permissions and application permissions, with the exception of permissions on the Microsoft Graph API.
Applications can have different privileges added to them, and a user in the Application Administrator role can add extra permissions to an application and theoretically use those credentials to impersonate the app's identity and have more privileges than originally intended.
An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources. Just as a user is represented by a security principal called a user principal, an app is represented by a service principal. The service principal provides an identity for your app, allowing you to delegate only the necessary permissions to the app. It improves security if you only grant it the minimum permissions level needed to perform its management tasks. So if you assign credentials to a service principal you can grant or restrict the app's access to certain resources.
I would like to assign the rights for mid-level admins to revoke 365 sessions for users in Office 365 (perhaps after accounts become compromised). What are the minimum rights necessary to allow an admin to revoke sessions.
One way is to grant the user User administrator role.
Can manage all aspects of users and groups, including resetting
passwords for limited admins.
You can run Revoke-AzureADUserAllRefreshToken command in powershell or call Azure AD graph api directly by using Azure AD Graph Explorer.
The other one is to create an application and grant it 'Directory.ReadWrite.All' permission.
This will allows the app to read and write data in your organization's
directory, such as users, and groups, without a signed-in user. Does
not allow user or group deletion.
Both of them include other permissions, not only 'Revoke-AzureADUserAllRefreshToken' permission. It depends on you which one include the least permissions for you.
For an application to work, it requires read/write access to most user calendars in the organization, which is achieved with app-only permission requirement for Graph API, which allows access to all calendars.
This looks a little bit too wide for some security people, and they asked me if there is some way to restrict this to a specific subset of accounts. I haven't found any settings in this direction. "Grant permissions" in App registration section of the Azure AD management portal will give access to all user calendars, including the future ones too.
Could somebody give a straight answer if it is or not possible; and I would be grateful for a link to an official Microsoft page where that can be seen.
Thank you!
Yes, there is a way. follow the steps below and wait 30 to an hour for policy to propagate.
Configure ApplicationAccessPolicy
To configure an application access policy and limit the scope of application permissions:
Connect to Exchange Online PowerShell. For details, see Connect to
Exchange Online PowerShell.
Identify the app’s client ID and a mail-enabled security group to restrict the app’s access to.
o Identify the app’s application (client) ID in the Azure app registration portal.
o Create a new mail-enabled security group or use an existing one and identify the email address for the group.
Create an application access policy.
Run the following command, replacing the AppId, PolicyScopeGroupId, and Description arguments.
New-ApplicationAccessPolicy -AppId e7e4dbfc-046f-4074-9b3b-2ae8f144f59b -PolicyScopeGroupId EvenUsers#contoso.com -AccessRight RestrictAccess -Description "Restrict this app to members of distribution group EvenUsers."
Test the newly created application access policy.
Run the following command, replacing the AppId and Identity arguments.
Test-ApplicationAccessPolicy -Identity user1#contoso.com -AppId e7e4dbfc-046-4074-9b3b-2ae8f144f59b
The output of this command will indicate whether the app has access to User1’s mailbox
Ref: https://learn.microsoft.com/en-us/graph/permissions-reference#calendars-permissions
Ref: https://learn.microsoft.com/en-us/graph/api/resources/calendar?view=graph-rest-1.0