I'm trying to develop an app in Teams to help team owners invite external guests to their teams. The app uses graph api /invitations call in the backend to get the job done. We are restricting users who can invite guests by assigning them the User.Invite.All api permission in Azure portal under AD App registration blade. What we found was that even users who have not been assigned this permission are able to invite guests. Am I doing anything wrong?
If you gave the delegated permission User.Invite.All to the app, and the user is able to invite a user, then the user already had rights to invite users.
They would be able to go to e.g. portal.azure.com, and invite users from there as well in that case.
If you gave the app permission User.Invite.All to the app, then any user using the app can invite users, since the app itself has the permission and the user info is not even present in the access token.
Related
I need to register office 365 users residing in another Azure AD to be created programmatically using microsoft graph API into Azure AD B2C directory. I am successful in creating and logging into local accounts but creating external identity users hasn't been successful. The microsoft documentation is verbose too for this context. The scenario is as under.
Invited the user using invitation API.
User accepts the invitation received in their email and gets redirected to grant permission screen for the app, and then lands on the redirect url.
The user can be seen in Azure B2C users as invited and then external azure ad after invitation acceptance
Problem:
The same user can't login using the Signin flow that works for the local accounts. I noticed the signInIssuerId is also null for this user. The error received states please sign up user first/no account found.
I understand there is some disconnection behind where the invitation is sent but the user is not signed up from the graph api. How can this be achieved? I would hate to know if that would be possible only using IDEF / custom policies
Please help!
The problem is that these are social/federated users, not local ones.
You need to use the "SocialAndLocalAccounts" policies in the starter pack.
Invitations via the API are for B2B users. This type of user is not supported in B2C.
For examples of B2C invitations, look here.
I've been evaluating Azure Active Directory B2C as a solution for an identity provider I need for an upcoming project.
During my evaluation I noticed the following behavior that I am not sure should be possible:
I am in my B2C tenant and I invite a new guest user. In this case it is for a different email address that I control. This email address has no association to this B2C instance nor the parent AD instance, the Azure account or anything related. It is a throw away account I am using for testing.
I get the invitation sent to that address and log in through a different browser in incognito mode. I create my account and complete that flow.
Now here is where I am slightly concerned with security:
Logged in as this user I am able to do the following:
Log into the B2C instance and see some top level info such as the TenantId, etc...
I do not see other users BUT I can click on the "New Guest User" button ("New User" is greyed out) and can attempt to create/invite users. I am blocked from all the operations I tried but it seems strange to surface this UI.
Even though it said the operation was blocked my invitation to another email address I control actually went through. I was able to go through the invitation flow. There were some errors and it even said the invitation code was not valid... but despite this the invitation completed and I was able to log into the tenant management UI with this new user.
This user was also able to create invitations.
I also see this new user that was invited by the guest in my user list logged in as the account admin.
So my questions are:
Is this by design? Why?
Is this a possible bug?
Can this be blocked?
Why can B2C guest users invite other users and initiate the flow?
Why can B2C guest users even log into the tenant management site?
I can't imagine why a default scenario would allow new users that have not been given any privileges to view your tenant and invite other guests. In my scenario this should not be possible.
The idea of guest users in B2C is to invite other people who can be admins.
These people are not local users.
If you want to invite people to be local users, use a magic link.
My AD tenant has user consent disabled, i.e., all permissions added to AD app registration need an admin consent.
For an application using static permissions/scopes (v1.0 OAuth/OpenId endpoint), is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Microsoft docs say: "The app needs to know all of the resources it would ever access ahead of time. It was difficult to create apps that could access an arbitrary number of resources." Does it mean that for my scenario, all users need to wait for admin consent before they can access the app?
I receive the below error when a user tries logging in to the app using the Open ID Connect flow. For reference, my login URL is similar to https://login.microsoftonline.com/{tenant}/oauth2/authorize?response_type=id_token&client_id=b8ad6a99-cd23-40a6-a1b4-1184af990aa2&redirect_uri=https%3A%2F%2Flocalhost%2F&state=13ccfb84-cfd1-4cb0-bfe3-bb2c227e19f7&client-request-id=4d76947a-0000-48af-aeff-7bc2d5e40000&x-client-SKU=Js&x-client-Ver=1.0.17&nonce=ef1caa16-d3fe-4523-a9c9-000000000000
is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Yes, you can.
When the admin consent the API permission of an AD App(App registration), the permissions essentially will be given to the service principal(Enterprise application) in your AAD tenant. Actually if you use the AD App in your tenant, the permissions are essentially from the service principal.
You could refer to the screenshot below, there are four permissions, the two permission has been granted.
Navigate to the Overview, click the option Manage application in local directory.
Then in the Permissions, you will find the two permissions which have been consent.
When you add the new scopes, the app will keep working, but it will only be able to access the old scopes until the admin consents to the new scopes.
Thanks!
Alex Simons
When registering a native application on the Azure AD 1.0 endpoint, and assigning Graph API permissions, it seems like consented permissions are 'cached' somewhere and can't be managed properly.
Example scenario:
Application registered and permission scopes (incl. ones requiring admin consent) assigned.
Administrator consents to the permission scopes
Simple user can use the app with consented permissions.
Permission scopes change (adding a new one for example)
Same admin doesn't get the consent form anymore
Simple user is stuck with "consent required, have an admin account?"
Another global admin must use the app for the first time to trigger the consent page.
Note that #7 doesn't always work; even if the other admin provides consent, simple users can't get through sometimes.
This is a multi-tenant application, yet when start using it in another tenant, I can not see its consented permissions in the AAD portal under enterprise applications.
Shouldn't permissions that have been consented to be listed in other tenants so that the admin can at least see what has been consented to?
Also, when I register an app on the V1.0 endpoint in my own tenant, I have an option to 'grant permissions' centrally, from the Azure AD portal for my tenant.
This option isn't available if I'm looking at an application that was registered in another tenant.
Am I overlooking something? Any help much appreciated.
When you change permissions, it does not automatically re-consent (for user or admin). You can find a detailed overview of this at Understanding user and admin consent.
You'll first need kick off the Admin Consent workflow. For a multi-tenant app this is done by adding prompt=admin_consent to your OAUTH URL and having an Admin authenticate.
Once that is done you can also force existing users to re-consent as well by adding prompt=consent to your Auth URL.
i am developing an app.i am using google provisioning api in this app.in documentation it is mentioned that admin account can acces provisioning app.there are various types of admin accounts in google apps for example
1.Super Admin
2.Groups Admin
3.User Management admin
4.Help Desk Admin
5.Services Admin
in these all profiles in which accounts we can enable provisioning api .please reply
You need to create a custom role and assign it permissions from the Provisioning API section (at the very bottom of the list of possible permissions. Delegated users who are granted rights to perform actions in the Control Panel will not be able to perform the same actions via the API unless explicitly assign Provisioning API permissions for their role.
See this help article for more details.
Jay