My organization operates a shared Azure tenant between two separate organizations.
I have a requirement to provide a third party application (working on behalf of just one of the orgs) Delegated Group.ReadWrite.All permission to Microsoft Graph.
I am just being ultra-cautious about what this may mean in terms of the tenant and both organizations, and appreciate similar questions have been posted.
So my understanding is
Group.ReadWrite.All grants the application permission to write to the O365 Group Calendar and SharePoint Group, delegated which means the application can only access Graph via a valid signed in application user?
This means whatever the signed-in user cannot do, neither can the application?
This also means that if the signed-in user has no permissions to access anything on the second organization (SharePoint site; O365 calendar) then neither can the application?
It would only be bad practice e.g. ICT accidentally adding in the wrong user etc that would result in the application having more rights than it should?
This is understandably confusing given this scope's .All suffix but you're understanding is correct. It sometimes helps to use a fictitious user as an example.
Let's say we have two users, Bob and Sally:
Sally is a member of the "Sales Executives" and "Corporate Leadership Team" groups.
Bob is a member of the "Corporate Leadership Team" and "Finance Executives" groups.
If you provide Delegated Group.ReadWrite.All to the application:
When Sally authenticates the application will only have access to the "Sales Executives" and "Corporate Leadership Team" groups. It would not have access to the "Finance Executives" group.
When Bob authenticates the application will have access to the "Corporate Leadership Team" and "Finance Executives" groups but not "Sales Executives".
Delegated permissions give an application to operate on behalf of a User. Regardless of the scopes granted, the application will be limited to activities otherwise granted to the User.
Application permissions on the other hand operate only on their behalf. If you were to grant Application Group.ReadWrite.All, the app would have permission to access any Group in the tenant (with some exceptions).
Related
I have an app (ASP.Net Classic) that is using Azure AD authentication. Now, we want to allow user outside of the organization to sign in. I read few document B2C and B2B, but I am unable to see which one to good for me.
I am looking that members in the organization should sign in and doesn't have to create new account. One of the option B2B suggested that to add user to in AD as a guest user but this is the manual process, it would be good if it can be automated. Also that doesn't describe how user would send the request to for login info.
It depends on your use case.
Imagine a large company. They have Azure AD for their employees. Now they want some suppliers to have access to their billing system. Those suppliers are guest users. That's B2B.
For guest users, an admin can send an invitation email that contains a redemption link.
B2C is for the customers of the company. They use the company's e-commerce system. They do not need access to the billing system.
B2C is self-service i.e. these users self-register and can change their profile or reset their password.
Is it possible to allow all users in a specific AAD tenant to access an app?
Something like a tenant trust. Tenant 1 trusts Tenant 2 and I can add 'tenant2\AllUsers' to a permission.
I want to allow all users of a partner tenant (current and future) to be able to access a SharePoint site and a few other apps.
I've looked at B2B but it requires invitations which is hard to manage at scale.
Entitlement management looks nice but requires P2 licenses and has lots of capabilities we just don't need.
Does anyone have a simple way to do a 'tenant trust'? Am I missing something?
Firstly, you have a misunderstanding of "tenant trust".
When we say tenant trust, it means the tenant trusts an app and then the app can access the data of that tenant. There is not a way to make a tenant trust another tenant.
Anyway, using the official admin consent URL you can grant admin consent for a whole tenant to an app.
See Construct the URL for granting tenant-wide admin consent.
https://login.microsoftonline.com/{tenant-id of partner tenant}/adminconsent?client_id={client-id}
Sign in with an admin account from partner tenant and do the admin consent. Then all users from partner tenant can sign in to this app.
For SharePoint user case, you can take advantage of self-enroll service. Please refer to Use SharePoint as a business-to-business (B2B) extranet solution and Create a B2B extranet with managed guests.
In our organization, we have been inviting guest users to our AAD Tenant to successfully share resources with our B2B partners. However, we have a fear that there may be some business users that have been oversharing with individuals (e.g. xxx#gmail.com accounts or Business accounts we don't approve of).
We would like to better monitor these scenarios, and I've been able to determine a user's source via the Azure Portal:
Here, we can easily see that this particular user is coming from an External Azure Active Directory.
Is there a Microsoft Graph API or Azure AD API where I can get this information, so we can write some automation around this? Also, is there a way to determine which tenant this user is homed in? I have played around with the Users endpoint a bit, but don't see this information...maybe there is a different endpoint or permissions scope that I need?
Thanks for any assistance!
You cannot get tenant information of a guest user, but we can handle users by domain the user belongs to. you can allow or block invitations to B2B users from specific organizations .Please refer to this document.
I am trying to read and write Birthday and Hiredate user properties using Microsoft graph API. I configured below app and delegated permissions.
I am getting access denied error as a normal user but working for azure admin.
Delegate
User.Read, User.ReadBasic.All, User.ReadWrite, Directory.AccessAsUser.All (admin only), Directory.Read.All (admin only), Directory.ReadWrite.All (admin only),User.Read.All (admin only),User.ReadWrite.All (admin only),
App
Directory.Read.All,Directory.ReadWriteAll (admin only),User.Read.All (admin only),User.ReadWrite.All (admin only)
Please help me which permissions needed for the app to read and write birthday and hire day properties for normal users.
You cannot have both Application and Delegated scopes active within the same token. Which are used are entirely based on the OAuth Grant you've used to obtain the token. You might find this article helpful: Application vs Delegated Scopes.
You've also chosen several scopes that require Admin Consent before they can be used within a tenant. Until you've obtained this consent, normal user's will not be able to authenticate. You might find this article helpful: v2 Endpoint & Admin Consent.
In terms of scopes, in order to read a user's profile (which holds those properties), you should only need User.Read. You can, and should, remove all of the other scopes you're requesting. When it comes to permission scopes, more is never better.
Note: both of the articles I mentioned above were written by me. Also, while they deal with the v2 Endpoint, the concepts in them apply to both AAD v1 and v2 OAuth endpoints
We have an application which uses AAD B2B collaboration to invite users. These users are created as guest users in our AAD. This all works great:
Users that have an AAD/Office 365 can use their normal credentials to sign in.
Users that don't have an AAD/Office 365 create their account in the invite redeem process, and can use it to sign in. Microsoft stores these acounts in an external, for us hidden AAD.
Situation:
An organization uses our application. This organization doesn't have an own AAD/Office 365 yet. We invite some employees of this organization in our AAD using their email addresses. They get guest accounts in our AAD.
After a while this organization gets its own AAD/Office 365, for their existing domainname. This domainname was previously used in the email addresses in the invite redeem process.
The AAD admin of the organization creates the AAD, and immediately sees existing user accounts: all the accounts that have been invited are shown in the AAD. He didn't expected this when creating a new AAD, and he doesn't know where they come from.
It appears the external, for us hidden AAD, has become visible to the AAD admin.
The AAD admin might decide to delete these accounts, to start with an empty AAD. As a result the employees aren't able to sign in anymore in our application.
Our application uses the Microsoft Graph API to invite the users.
Is there a way to mark the users in the external hidden AAD in some way to make clear where the accounts are coming from? Like mentioning our organization/application in an existing field?
So to be clear: We don't want to set properties on the guest account. We want to set properties on the user account that an AAD admin sees when he has created the AAD. We want to make clear he must not delete this user, because it's created by/for application X.
No, this is a feature of Azure AD.
A domain owner can choose to take over the hidden Azure AD if they choose to create one later.
They control the domain, and thus control the users so it is up to them.
Now of course if you create an AAD Guest user with a Gmail account, they don't actually get added to a huge hidden Google Azure AD.
If AAD thinks the account is a social account, currently they create a personal Microsoft account transparently for that user (so the user always is in control of their account).
So if you invite users using their work emails, you must expect their domain owner to have control over their users' accounts.
AFAIK, there is no property that you could set.