1- We created a webpart to change user’s password using app services / graph api (/users/username {passwordProfile:{“password”:”xxxx”})
2- Because Directory.AccessAsUser.All is a delegated permission we need to add the user to the right role in order to get the access to change the password.
3- We tried adding the user to different roles and none of them worked but global admin. We always got insufficient privileges to complete the operation”
Is there a way to do this with less privilege then Global Admin?
Password changing is one of those privileged roles that cannot be just given in application api permissions.
2. that is correct. The Directory.AccessAsUser.All permissions is delegated only which means only users with the correct role can perform the functionality. See below for roles that can change passwords.
You should be able to change the passwords using the application only without delgated permissions for graph. you can if you assign the service principal of the app (app registration) to the Password Administrator role in azure ad. if you manage any other properties, you may be better off giving it Helpdesk administrator Role. same applies for the delegated user, if you put them in one of those 2 roles they should have access to change the passwords.
If you want to give a role other than Global Admin role you can try with the Privileged authentication administrator which can also help you modify the password for other users.
Make sure you have the Directory.AccessAsUser.All permission as well with the role to modify passwordProfile property.
Related
I'm trying to programmatically determine which Graph permissions a user is inheriting when it's assigned to a specific AAD Directory role. When you look at a built-in Azure Active Directory role, its permissions are listed in the form of a path. For example, for the Global Reader role, the first one is
microsoft.directory/accessReviews/allProperties/read, as displayed on the Azure portal
or using the Microsoft.Graph Powershell module:
PS> $roleDef = Get-MgRoleManagementDirectoryRoleDefinition -Filter "DisplayName eq 'Global Reader'"
PS> $roleDef.RolePermissions.AllowedResourceActions
microsoft.directory/accessReviews/allProperties/read
microsoft.directory/accessReviews/definitions/allProperties/read
However, Graph permissions are usually expressed in this format: User.Read, Directory.ReadWrite.All. For example, for a user, you can check its delegated and application permissions with:
Get-MgUserOauth2PermissionGrant -UserId $userId
Get-MgUserAppRoleAssignment -UserId $userId
I have 2 questions:
Why the difference between AAD Role permissions and Graph permissions ?
How can I map AAD Directory Role permissions to Graph permissions ?
I just got confirmation from a Microsoft engineer that it's not possible to map built-in AAD role permissions to Graph permissions.
Azure AD built-in roles will grant access to data that's also possible through Graph permissions, but Graph permissions allow for more granular management of access to data.
With this said, certain endpoints will require you to have both Azure AD built-In roles and Graph permissions.
For example, the "delete user" endpoint requires the logged-in user to have at least the User Administrator role to proceed.
I have a requirement to list a subset of my AAD users, identify the manager, and disable the user if the manager is already disabled.
My account has the 'User Administrator' and 'Global Reader' AAD roles.
This task is easy to accomplish using the AzureAD PowerShell cmdlets, however I want to transition to the Microsoft Graph cmdlets.
I understand that I need the scope User.Read.All so I execute the following command:
Connect-MgGraph -Scopes "User.Read.All"
When I log in via the web interface, I am shown a dialog stating that I need consent from an admin (which I understand to be a user with an AAD role of Global Administrator or Application Administrator).
In my tenant, under 'Enterprise Applications > User Consent Settings', the option 'Allow user consent for apps' is selected.
This seems like a step backwards to me. My user has the necessary permissions to perform the required actions, but because MS Graph uses an Enterprise App I need an administrator to grant consent.
My questions are:
Will the admin consent dialog appear every time I execute Connect-MgGraph with a given scope, or just the first time?
Is there a way to achieve my requirement without admin consent?
Question 1
Admin consent can be given in 2 contexts
On behalf of a specific user
On behalf of your organization (all users)
From the admin consent dialog box, which context it is corresponds to the checkbox Consent on behalf of your organization
If you do not give consent on behalf of the entire organization, the admin consent dialog will appear for each user, until consent has been granted either for that user, or the entire organization.
Question 2
There are 2 types of permissions
Delegated (aka Scope)
Application (aka Role)
All Application permissions require admin consent, and SOME delegated permissions require admin consent.
This document details which MS Graph permissions require admin consent, from the column Admin Consent Required
Microsoft Graph permissions reference
You can see that the User.Read.All delegated permission is one that does require admin consent
User.Read.All permission reference
There's no way around this without granting admin consent. This provides a way to control access to applications on a more granular level.
I created an app that displays SignInActivity pulled from a Microsoft Graph api query.
When running as a normal user it gives the error: User is not in the allowed roles.
To fix this error you need to give the user the "Global Reader" role within o365.
Questions:
Is there an App security scope that will allow a user to view SignInActivity even if they don't have the "Global Reader" role?
The app already has the scope AuditLog.Read.All. This was needed to run the query.
Is there a way to use Microsoft Graph api to verify a user has the "Global Reader" role?
You can check the scopes through Microsoft Graph Api by decoding the access token, you can try to login into https://developer.microsoft.com/en-us/graph/graph-explorer with work or school accounts (Azure AD), you can just look inside the access token to see a list of permissions by decoding the access token into https://jwt.io/
I understand that for an app to access Office365 mailboxes I need a registered app with Application Permissions, e.g. Mail.Read which - according to its description - "allows the app to read mail in all mailboxes without signed-in user".
This is exactly what I need except I don't need and I am not allowed to read all mailboxes within the organisation.
In order to restrict this further I can of course set a ApplicationAccessPolicy which allows to restrict the access to a specific mailbox or generally a PolicyScopeGroupId.
My issue is that when this policy is not active, changed or deleted for whatever reason an app has full access to all of organization's mailboxes which sounds very risky in a bigger enterprise.
Isn't there really any other way to handle that vice versa, so that by default no mailbox can be accessed except a set of defined ones?
The other way around can be,There is a separate Mail.Read permission for both Application and Delegated permissions.
The difference between "App-only vs. delegated permissions"
Permission scopes can be either app-only or delegated. App-only scopes (also known as app roles) grant the app the full set of privileges offered by the scope. App-only scopes are typically used by apps that run as a service without a signed-in user being present.
Delegated permission scopes are for apps that act on behalf of a user. These scopes delegate the privileges of the signed-in user, allowing the app to act as the user. The actual privileges granted to the app will be the least privileged combination (the intersection) of the privileges granted by the scope and those possessed by the signed-in user. For example, if the permission scope grants delegated privileges to write all directory objects, but the signed-in user has privileges only to update their own user profile, the app will only be able to write the signed-in user's profile but no other objects.
"Permissions not requiring administrator's consent" are delegated permissions, while "App-only permissions requiring administrator's consent" are the app-only permissions, which is why it shows up twice.
If you want to access the mail for all the user's in your tenant, then you must have a user account that has that level of access or you need to use an App Only token which grants that scope of access.
We are creating a service that requires permission to view other users' (inside the organization) emails. I'm under the impression that two required permissions are Mail.Read and Directory.Read.All. Since I'm not an admin, I got our admin to try it and he still gets 'Access denied'. Is it possible for the admin to give me the necessary directory permissions?
Am I missing something?
(Sorry if I am ambiguous, I am brand new to Graph. Please ask me any question that will help clarify)
Make sure you've enabled the Mail.Read application permission (Read mail in all mailboxes). There is also a Mail.Read delegated permission (Read user mail), which gives you access only to the signed-in user's mailbox.
An admin must grant that permission in Azure Portal for the application. From that point on, the application by itself (with no signed-in user) should be able to access any user's email in the organization.