I am trying to revoke the refresh tokens of a specific user (my own) in AzureAD to force a completely new logon to an applicaiton.
As there is no UI option for this in the Azure Portal (there actually is -> see in one of the anwers) I am using the 'Windows Terminal's 'Azure Cloud Shell' option as follows directly from the built-in Azure Cloud shell:
Connect-AzureAD
PS /home/...> Revoke-AzureADUserAllRefreshToken -ObjectId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
The GUID I pass in the parameteter is the object ID of my user.
Unfortunately this fails due to a permission issue:
Revoke-AzureADUserAllRefreshToken: Error occurred while executing RevokeUserAllRefreshTokens
Code: Authorization_RequestDenied
Message: Access to invalidate refresh tokens operation is denied.
RequestId: fd5f5256-3909-46af-b709-8068e0744f25
DateTimeStamp: Mon, 09 Aug 2021 16:56:28 GMT
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
If I try to execute the same in the Cloud Shell within the azure portal, the result is the same.
If I use a 'classic' PowerShell, then it works. So apparently something is missing with the authentication of the Cloud Shell.
When I log in I get to select the right tenant, and my read access e.g. to the user list works perfectly.
I have no more clues what I would be missing:
I am Owner of the subscription in the azure role assignments
I do have the Global Administrator role assigned in AzureAD
Is there some special command to 'elevate' the permissions?
I tried to reproduce the issue on my Azure AD tenant , but unfortunately I didn’t receive the error you are getting .
Note: Make sure you connect with AD with your Global Admin account i.e. admin#domainname.onmicrosoft.com or username_outlook.com#EXT##domainname.onmicrosoft.com, so that you see the correct details in every column in the above red box.
Other options :
From Portal you can go to the user profile and click on revoke
sessions .
Using Graph Explorer you can revoke signin Sessions.
Post https://graph.microsoft.com/v1.0//users/UserObjectID/revokeSignInSessions
Reference:
user: revokeSignInSessions - Microsoft Graph v1.0 | Microsoft Docs
Related
As per MS article only GroupMember.Read.All permission is required to list the group owner. I assigned this API permission to my Azure AD application. however, when I run the below query it throws the 403 error. It works without "$expand=owners" parameter
https://graph.microsoft.com/v1.0/groups?`$expand=owners
Error
Invoke-RestMethod : The remote server returned an error: (403) Forbidden.
Also, the above graph query works if assign Group.Read.All permission. But I don't want to assign this permission it will allow the application to read calendars, conversations, files, and other group content of all groups.
Please note that we have more than 2 million groups in Azure AD. So running two separate queries for the group and owner will be very time-consuming.
I tried to reproduce the same in my environment by granting GroupMember.Read.All permission and got the 403 error like below:
https://graph.microsoft.com/v1.0/groups?$expand=owners
Response:
Using GroupMember.Read.All permission, you cannot expand the owners($expand=owners) but can list the owner of specific group like below:
https://graph.microsoft.com/v1.0/groups/GroupID/owners
Response:
Please note that you must need Group.Read.All permission to expand owners($expand=owners) that includes owners of all groups in response.
https://graph.microsoft.com/v1.0/groups?$expand=owners
After granting Group.Read.All permission, got the response successfully like below:
Response:
References:
Use query parameters to customize responses - Microsoft Graph | Microsoft Docs
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
I would like to automate deployment and it requires to update settings for Azure AD Application registration.
So far I am able to :
create an Azure AD Appregistration and Service Principal with certificate (thx MS documentation)
then use command Connect-AzureAD with previous service Principal with its certificate
use command like Get-AzureADApplication -ObjectId 11111111-2222-3333-4444-555555555555
In previous bullet ObjectId 11111111-2222-3333-4444-555555555555 match with application i created on first bullet
However i am unable to execute command like:
Get-AzureADApplication -Filter "DisplayName eq '$aADApplicationame'"
and $aADApplicationame matches with application created previously
Set-AzureADApplication -ObjectId $aADApplication.ObjectId -ReplyUrls $ReplyUrls
Get-AzADServicePrincipal
I get following error message
Set-AzureADApplication : Error occurred while executing SetApplication
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation
Based on my research, i set up some API permissions as follow:
Unfortunately no luck and still get insufficient privilege although all permissions were granted.
Do you know if I miss something ? Is there any specific permissions i should add to make it works ?
Regards.
As mentioned by another reply, you could give the Global Administrator role to the service principal, it is correct, but the permission of Global Administrator is too large in this case, it may cause some security issues.
In this case, the commands Get-AzureADApplication and Set-AzureADApplication you used essentially call the Azure AD Graph API, so to solve the issue, a better solution is to add the permission of Azure AD Graph API, please follow the steps below.
1.Navigate to the API permissions of your AD App -> select Azure Active Directory Graph(not Microsoft Graph).
2.Select Application permissions(not Delegated permissions) -> Application.ReadWrite.All -> click Add permissions.
3.At last, click the Grant admin consent for xxx button.
After a while, try the commands again, it will work fine.
Update:
After I check the doc, I find there are already some new commands released by MS which call the Microsoft Graph, haven't seen them before.
e.g. In your case, you can use Get-AzureADMSApplication instead of Get-AzureADApplication.
Get-AzureADMSApplication -Filter "DisplayName eq 'joyttt'"
Use Set-AzureADMSApplication instead of Set-AzureADApplication.
Set-AzureADMSApplication -ObjectId <object-id> -Web #{ RedirectUris = "https://mynewapp.contoso.com/" }
For Get-AzADServicePrincipal, there is no equivalent currently, there should be one in the future. When using the commands above, the permissions of Microsoft Graph will work, no need to use Azure AD Graph, but you should use Application permission, not Delegated permission (you used the Delegated permission in your question.)
You are facing this issue because Powershell cmdlet works differently than compared to MS Graph. Instead of permissions, Powershell require roles to do this operations. Please add Global Administrator role to your service principle and then try the Connect-AzureAD so that, the issue will be fixed.
For more details, you may refer to Assigning administrator roles in Azure Active Directory.
I was also facing similar issue, make sure are doing below two things:
Set Run as account for azure automation account
In newly created app registration for azure automation account after setting Run as account, make sure you add Cloud application administrator role explicitly.
Add API permission for Application.ReadWrite.All (Microsoft graph)
In my case the app registration was showing cloud application administrator role under Roles and Administrator screen, which I thought gives the new app registration required permission but that was not the case. PowerShell script only worked after we assigned the cloud application administrator role explicitly.
In the beginning thanks for previous posts it gave a lot of inspiration according topic. Problem occurred in our case at automated bicep mechanism that is supposed to add API permissions for Microsoft Graph.
Error: Authorization_RequestDenied
Solution:
We needed to give Enterprise Application running mechanism Microsoft Graph (not Azure Active Directory Graph it will be deprecated) Application permissions:
Application.ReadWrite.All
AppRoleAssignment.ReadWrite.All
Directory.ReadWrite.All
I am trying to run a PowerShell script for assigning appRoles from a DevOps service principal.
The DevOps service principal has the following permissions assigned and admin consented:
Application.Read.All
AppRoleAssignment.ReadWrite.All
User.Read
It fails on the step where it gets the service principal which is the owner of the roles to assign:
$sp = Get-AzureADServicePrincipal -filter "displayName eq '$AppName'"
with the error message:
Error occurred while executing GetServicePrincipals
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
RequestId: a8fadf67-94d6-40ec-ad88-6562cf9f6d80
DateTimeStamp: Tue, 23 Jun 2020 16:51:36 GMT
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
I expected Application.Read.All to grant this permission, since the resource I am searching for is an Application.
What permission do I need to run this line of script, and where is this documented? I am applying the principle of least-privilege and don't want to give the Devops sp an administrative role. I only want to apply the specific permission required to do the job.
I notice that you assigned a permission User.Read which only exists in Delegated permissions. So I guess the other 2 permissions Application.Read.All and AppRoleAssignment.ReadWrite.All you configured are also Delegated permissions.
But now you are run Get-AzureADServicePrincipal from a service principal, that means it needs Application permissions (no user here).
And when I track this cmd via Fiddler4, the backend request is GET https://graph.windows.net/exxxxx4e-bd27-40d5-8459-23xxxxa757fb/servicePrincipals?api-version=1.6&%24filter=displayName%20eq%20%27xxxx%27
graph.windows.net is for Azure AD Graph and graph.microsoft.com is for Microsoft Graph.
So it is calling Azure AD Graph instead of Microsoft Graph. What you need are Application permissions of Azure AD Graph.
Based on my test, Application.ReadWrite.All and Directory.Read.All can meet your needs. If you don't want the service principal to have the write permission, you can choose Directory.Read.All.
My question is, do we have any documented method of granting a Manage Service Identity permissions to the Graph API as we would with an Azure App Registration in the portal? I was unable to find any Powershell options or ability to manage permissions for the MSI service principal in the Azure Portal or documentation. I found a similar question on MSDN forums, but wanted to make sure there were not any further updates or workarounds that anybody knew of?
MSDN Forum Post: https://social.msdn.microsoft.com/Forums/azure/en-US/dae34534-f193-4444-b52e-ba9cfa4a1fda/does-azure-msi-support-accessing-graph-api?forum=WindowsAzureAD
Disclaimer - I'm not overly familiar with MSIs, but as they are modeled as service principals, this should work. Also I'm not able to validate these steps.
These steps require that you use Azure AD PowerShell (v2) to assign application permissions to your MSI (to access Microsoft Graph), and that you are an administrator or app admin in your tenant. For Microsoft Graph, the documented permissions can be found here. The same instructions could be used for other resources secured by Azure AD too. I'll assume that you've already installed the PowerShell module.
Connect-AzureAD to connect PS to Azure Ad. Enter your admin creds.
$graph = Get-AzureADServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" to find the service principal representing Microsoft Graph and assign it to a variable. The service principal for Microsoft Graph is currently created just in time on first access, so there is a possibility it doesn't exist. It can be created by calling New-AzureADServicePrincipal -AppId "00000003-0000-0000-c000-000000000000".
$graph.AppRoles - this will show you all the available application permissions that you can choose from that are exposed by Microsoft Graph. For example if your MSI needs to read group information, find the "Group.Read.All" permission from the list, and make a note of its permission Id (it's a GUID). For example here's one of the records from the AppRoles list:
AllowedMemberTypes : {Application}
Description : Allows the app to read events of all calendars without a signed-in user.
DisplayName : Read calendars in all mailboxes
Id : 798ee544-9d2d-430c-a058-570e29e34338
IsEnabled : True
Value : Calendars.Read
Find your MSI's objectId (assuming you don't know it, but that you do know its clientId/appId):
$msi = Get-AzureADServicePrincipal -Filter "AppId eq '{Your_MSI_appId}'"
For each of the permissions your MSI needs, run the following PS cmdlet to assign the permission to your MSI:
New-AzureADServiceAppRoleAssignment -Id {permissionId} -PrincipalId $msi.ObjectId -ResourceId $graph.ObjectId
And that should do it. You should now be able to acquire an access token for your MSI to call Microsoft Graph, and the access token should contain a roles claim that matches the permissions (ids) that you've assigned above. You can then use that access token to call Microsoft Graph. This is similar to steps 6 and 7 in https://learn.microsoft.com/en-us/azure/active-directory/msi-overview.
Hope this helps,
The RequestDenied message is expected. There was a change to this that updating the System MSI SP is now blocked.