Our application is mainly used by internal users, who authenticate through AAD. Some pages need to be accessible to third-parties. Right now we are using custom tokens, but would like to switch to Azure AD B2B Invite API.
We just did some manual test runs and it seems to work exactly as expected, except for one thing: when inviting my standalone email address, I was asked to create a Microsoft account, which is fine. However, to do so, I had to first verify my email address (code sent to email) and then my phone (code sent via sms).
Is there any way to disable ideally both or at least the phone verification?
The only resource I found so far states that it's possible in B2C, which is not what we want.
The standalone email addresses has to undergo the invitation redemption process. In order to be able to invite people without redemption in Azure AD B2B you need an account with directory read permission of the partners tenant. Then you can add that user to your tenant with "Guest Inviter" role. Then that user can add the users to your tenant without invitation redemption process. Refer: Azure AD B2B: How to bulk add guest users without invitation redemption.
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 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.
I have a B2B AAD tenant I am using for authentication for my app, and inviting users to it using Microsoft graph invitation API. Unfortunately some users have either both a work and personal account, or just a personal account linked to the email, and there doesn't seem to be any way I can restrict the invitation to their work account (or in the case of just a personal account, force the creation of a shadow tenant).
Is it possible to only invite work accounts? Or force users to sign in with a work account?
As far as I know, there is no way to specify this requirement when sending an invite.
Would be a good parameter to have though.
When signing in, you can force the user to use a work/school account by adding msa_fed=0 to the URL.
If you are using the v2.0 endpoint, you can use the organizations endpoint instead of common.
Note that both of these rely on setting a URL parameter which the user could easily manipulate.
So you would probably want to also check on the app side that the tenant id is not the MS account tenant id. (9188040d-6c67-4c5b-b112-36a304b66dad)
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.
How to create invitation policy on Azure Active Directory and use it to send invitation to user for Business to Business (B2B) and Business to Consumer (B2C) in a web application? I use invitation API for Azure AD B2B to send invitation, but can't send when used in Azure AD B2C.
At this time, Azure AD's B2B collaboration feature and Azure AD B2C are not compatible. Azure AD B2C does not have any built-in invitation mechanism as it is tailored for self-service registration via the signup and signup/signin policies. There is an existing feedback request you can vote for: AADB2C: Send email invitation for new user to sign up.
You can implement this yourself by creating your own invitation UI. This UI would call the Azure AD graph to create the users.
You can then either:
Use the password reset policy as their first time experience since that sends an email to the user with a code. Note that you have very limited control over the look & contents of this email.
OR, create your own "redeeming" or "activation" mechanism, for example:
Ensure you set accountEnabled to false when creating the user.
Create an activation code/link and email that to the user (using SendGrid for example). You'll need to be able to associate that code/link to the user somewhere/somehow.
Once the user navigates to the link or uses the code, update the user via the Graph again to set its accountEnabled flag to true.
Note: this will only work for local users and not for social users.