Invalid tokens with graph explorer - azure-active-directory

is it possible to revoke all azure ad tokens with graph explorer?
As with this PowerShell cmdlet: Revoke-AzureADUserAllRefreshToken
BR
Thomas

You could use Graph API in the graph explorer:
POST https://graph.windows.net/myorganization/users/{user_id}/invalidateAllRefreshTokens?api-version
For more details, refer to this article.

Short: I don't think so.
What is the goal ? Is it to disallow a single user, or all users in a tenant?
There isn't a refresh token for a user, only an access token as this is a single page application using the implicit grant flow. I think the best that they can do is to turn off user consented access. What I don't know is whether user consent can be turned off per app, per user, or only across an organization. I have no idea about the granularity of that control. I've only heard of this type of control so I've never done it myself.
Access tokens granted to GE last 60 minutes.

Related

Microsoft Graph external user access

I have an issue with accessing user data with microsoft graph api.
Context : I have a web app with a calendar inside for my users. I would like to give the user the possibility to synchronise this calendar with their microsoft calendar. I did the same thing with google calendars and it works well.
Problem : I registered an app on azure and setup my code with the correct access to login and get a token from the graph api.
It kinda works but i can only log in with the address i used to create my app on azure.
So lets say my admin address on azure is test#azure.com , then i can log in and access the data i want . But if i try with another address like for example test#customer.com, then it fails and display this message :
I keep looking for a way but the Microsoft graph documentation doesn't seem to talk about this problem.
I tried to add the account as an external user, like the message says (and maybe i did it wrong i'm not really sure of this part) but then i can log in but the data i can access doesn't match the data on the account i tried with, as if adding the user as an external user created a "new" user in my organisation.
What I want : I would like to be able to access the data of any user that try to log in with a microsoft email (if they accept the permissions of course).
It's my first time using the graph api so maybe i'm missing something simple...
Thanks
Based on the So thread reference:
When a user authenticates against your tenant, you only have access to the data controlled by your tenant. In other words, if test1#outlook.com authenticates against yourtenant.onmicrosoft.com tenant, you don't gain access to their outlook.com email.
Reason you're able to see the outlook.com email from Graph Explorer is that Graph Explorer is authenticating against their outlook.com account.
In other way, Graph Explorer is authenticating test1#outlook.com against the outlook.com tenant, not yourtenant.onmicrosoft.com.
When a user authenticates against a given tenant, that token only provides access to data within that single tenant. Microsoft Graph does not allow you to cross tenant boundaries.
Thanks Hong for the comment, you may also set your app registration to "multitenant + personal accounts"
So Reference: MS Graph External User 401 Unathorized

Running into 'serviceUnavailable' SharePoint graph query forever when combining Azure AD App permissions

This situation made me create a real monstrous work-around, but sometimes, you don't have an option right?
The problem is basically bumping into 503: 'serviceUnavailable' messages when several (specific?) Azure AD Application permissions are set in your Azure AD Application, which should not happen.
Context and technical queries
The context is specifically for Application permissions (app-only auth) and NOT delegated permissions. Token is retrieved by:
HTTP POST https://login.microsoftonline.com/e6fcb01a-f706-4b1b-872b-1e7645d78491/oauth2/v2.0/token
headers:
Content-Type=application/x-www-form-urlencoded
-------------
client_id=<App GUID>
client_secret=<App SECRET>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials
/sites/root query retrieved by:
HTTP GET https://graph.microsoft.com/v1.0/sites/root
headers: Authorization=Bearer <AccessToken>
-------------
Reproduce this situation:
Create an Azure AD Application
Add Application Permission > Sites.ReadWrite.All
Grant Admin Consent for
Create Secret
Generate Access Token (using)
Run Query with token (works)
Forcing it to break (either add all at once or 1-by-1)
Add Application Permission > Group.Create
Grant Admin Consent for
Generate Access Token
Run Query with token (fails?)
Does it work?
Add Application Permission > Group.ReadWrite.All
Grant Admin Consent for
Generate Access Token
Run Query with token (fails?)
Repeat for another permission. until it breaks.
Does it break?
Fails forever
Workaround:
Split up App Permission across multiple AD applications.
I tested this and the issue is there but a workaround is you don't need Group.Create permission if you have Group.ReadWrite.All.
So in summary a single AD app can have Group.ReadWrite.All and Sites.ReadWrite.All permission and it will work but a single AD app will fail if it has all three permissions of Group.Create, Group.ReadWrite.All and Sites.ReadWrite.All
Based on my test (Did not test all permissions), the issue does exist.
There are two main permissions that affect the calling of this API endpoint.
They are Group.Create and Group.Selected.
I'm not sure why they cause the failure of the calling of /sites/root. But it's strongly recommended to remove these two permissions (maybe there are some more other permissions) from the Azure AD app which is used to access /sites/root.
At the same time, opening a support ticket on Azure portal for your Graph request is a good choice.
Unfortunately this was a previously known issue in SharePoint. A fix is on its way but I don't have an ETA for rollout to share.

Restricting Microsoft Graph (or Azure AD Graph) read permissions

Further to the question raised here
Get all user properties from microsoft graph
Yes, I can obtain full user profile data using the graph query but from the perspective of the tenant, can I restrict the graph query to only be able to access the basic profile data?
Azure AD graph has delegated permissions for user.readBasic.all which restricts this. We have a 3rd party app that accesses the Azure directory to retrieve basic data to set up accounts in its user directory and we need to restrict this to the basic data due to the security risk. We cannot rely on the 3rd party just doing the right thing all the time.
So I need a way to set the app to allow app permissions (not delegated as the read occurs every 4 hours without human involvement) for user.readBasic.all.
If you want restrict the returned field from the "user.readBasic.all", the best way is you implement a custom handler(API/Service and so on). No directly official channel to do this now. (user.readBasic allows the app to read the full profile of the signed-in user, because after the user sign-in it means he has authorized the APP to get his information.)
You can check the blog for graph permission for here: https://blogs.msdn.microsoft.com/aaddevsup/2018/05/21/finding-the-correct-permissions-for-a-microsoft-or-azure-active-directory-graph-call/
And for the detail of the "user.readBasic.all" you have pointed from official link(https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference#user-permissions) Allows the app to read a basic set of profile properties of other users in your organization on behalf of the signed-in user. This includes display name, first and last name, email address, open extensions and photo. Also allows the app to read the full profile of the signed-in user.

Delegate and impersonate as a user with admin/app credentials

One thing I do currently in an enterprise app is logon to a single admin email account that has delegation over other users and using delegation, we are able to manipulate email/calendar/contacts of users.
I'm looking to use the Microsoft Graph API and I have managed to use admin delegation and gain access to various resources, however last modified (on Onedrive/Sharepoint) is showing the app instead of an individual user.
I understand I can use Oauth and logon as individual users, capture a token and then do what I need under the context of that user, but, I need to do this server side where tasks run. Is there anyway to use admin approved delegation/impersonation from the app so that the users don't have to signin?
e.g. standard that works:
https://graph.microsoft.com/v1.0/sites/my-site.office.com/drive/root:/file.txt:/content
Looking to add a user tag, but this doesn't work:
https://graph.microsoft.com/v1.0/user/{id-of-user}/sites/my-site.office.com/drive/root:/file.txt:/content`
After searching for ages, the closest I have read seems to be in here however, I was wondering if there was a standard way of doing this - I haven't been able to get the JWT part of this working (and not sure if this is even the correct thing I am looking for).

Authentication Process Get Azure AD group the user is a member of and do logic

Is there a way to get the Group the User is member of so we can process the authentication, or even throw exception so the token will not be created.
The reason we need groups is that we can not create OU in Azure AD whereas we could before in LDAP. We retrieved the distinguished name and therefore had very rich information about said user.
Lastly, we do see that you could create an OU on-premises but read that Graph API would not recognize it or could not retrieve it.
We are attempting to do logic within the SecurityTokenValidated stage of Authentication process and we break the process whenever we try to use:
string UPN = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.Name).Value
Is this because we are using MSAL?
The best approach for you to take here is to make use of the group claims capability of Azure AD. (And for get OUs. OUs are not represented in Azure AD at all.)
Dushyant Gill's blog post on this is relatively old, but still very much relevant: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/. In short, the process is:
Enable group claims for your application by setting the groupMembershipClaims property in your application. After setting this, when a user signs in to your application, the list of groups they are a member of will be included in the token (if the number of groups is smaller than the limit).
Update your application's authorization code to make use of the group membership claims (if present).
Update your application to query the Azure AD Graph API if the groups membership claim is not present (i.e. if the "overage" claim is present). This happens only when the user is a member of more than 150-250 groups. (Use the _claim_name and _claim_sources claims as indications that the Graph API needs to be called directly.)
As described in the documentation for Azure AD Graph API permissions, in order for your application to call the getMemberGroups method, the app must have the "Read all groups" permission (Groups.Read.All). This permission requires admin consent, but once consent has been granted, the request can be made using the signed-in user's access token.

Resources