0% found this document useful (0 votes)
221 views136 pages

Azure Ad b2b

Uploaded by

museg27
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
221 views136 pages

Azure Ad b2b

Uploaded by

museg27
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 136

Contents

Azure Active Directory B2B documentation


Overview
What is B2B guest user access?
Compare B2B with B2C
Quickstarts
Add guest users in the portal
Add guest users with PowerShell
Tutorials
Bulk invite B2B guest users
Enforce multi-factor authentication
Samples
Self-service sign-up portal sample
Code and Azure PowerShell samples
Concepts
B2B licensing
B2B and Office 365 external sharing
Invitation redemption
Invitation email
Understand the B2B user
B2B user claims mapping
B2B user token
Conditional Access for B2B
B2B for hybrid organizations
Current limitations
How-to guides
Manage B2B sharing
Manage invitations
Admins adding B2B users
Information workers adding B2B users
Google federation
One-time passcode authentication
Direct federation
Example of direct federation with AD FS
Allow or block invitations
Add B2B users without an invitation
API and customization
Manage guest accounts
Add a B2B user to a role
Dynamic groups and B2B users
Understand the B2B user
B2B for Azure AD integrated apps
Manage access in a hybrid organization
Grant local users access to cloud apps
Grant B2B users access to local apps
Leave an organization
Auditing and reports
Troubleshooting B2B
Reference
Invitation manager API
Resources
FAQ
Getting support for B2B
Azure feedback forum
Azure Roadmap
MSDN forum
Pricing
Pricing calculator
Service updates
Stack Overflow
Videos
What is guest user access in Azure Active Directory
B2B?
8/14/2019 • 2 minutes to read • Edit Online

Azure Active Directory (Azure AD ) business-to-business (B2B ) collaboration lets you securely share your
company's applications and services with guest users from any other organization, while maintaining control
over your own corporate data. Work safely and securely with external partners, large or small, even if they don't
have Azure AD or an IT department. A simple invitation and redemption process lets partners use their own
credentials to access your company's resources. Developers can use Azure AD business-to-business APIs to
customize the invitation process or write applications like self-service sign-up portals.
Watch the video learn how you can securely collaborate with guest users by inviting them to sign in to your
company's apps and services using their own identities.
The following video provides a useful overview.

Collaborate with any partner using their identities


With Azure AD B2B, the partner uses their own identity management solution, so there is no external
administrative overhead for your organization.
The partner uses their own identities and credentials; Azure AD is not required.
You don't need to manage external accounts or passwords.
You don't need to sync accounts or manage account lifecycles.

Invite guest users with a simple invitation and redemption process


Guest users sign in to your apps and services with their own work, school, or social identities. If the guest user
doesn’t have a Microsoft account or an Azure AD account, one is created for them when they redeem their
invitation.
Invite guest users using the email identity of their choice.
Send a direct link to an app, or send an invitation to the guest user's own Access Panel.
Guest users follow a few simple redemption steps to sign in.
Use policies to securely share your apps and services
You can use authorization policies to protect your corporate content. Conditional Access policies, such as multi-
factor authentication, can be enforced:
At the tenant level.
At the application level.
For specific guest users to protect corporate apps and data.

Easily add guest users in the Azure AD portal


As an administrator, you can easily add guest users to your organization in the Azure portal.
Create a new guest user in Azure AD, similar to how you'd add a new user.
The guest user immediately receives a customizable invitation that lets them sign in to their Access Panel.
Guest users in the directory can be assigned to apps or groups.
Let application and group owners manage their own guest users
You can delegate guest user management to application owners so that they can add guest users directly to any
application they want to share, whether it's a Microsoft application or not.
Administrators set up self-service app and group management.
Non-administrators use their Access Panel to add guest users to applications or groups.

Use APIs and sample code to easily build applications to onboard


Bring your external partners on board in ways customized to your organization’s needs.
Use the B2B collaboration invitation APIs to customize your onboarding experiences, including creating self-
service sign-up portals.
Use the sample code we provide for a self-service portal on GitHub.
Next steps
Licensing guidance for Azure AD B2B collaboration
Add B2B collaboration guest users in the portal
Understand the invitation redemption process
And, as always, connect with the product team for any feedback, discussions, and suggestions through our
Microsoft Tech Community.
Compare B2B collaboration and B2C in Azure Active
Directory
7/22/2019 • 2 minutes to read • Edit Online

Both Azure Active Directory (Azure AD ) B2B collaboration and Azure AD B2C allow you to work with external
users in Azure AD. But how do they compare?
Azure AD B2B is for businesses that want to securely share files and resources with external users so they can
collaborate. An Azure admin sets up B2B in the Azure portal, and Azure AD takes care of federation between your
business and your external partner. Users sign in to the shared resources using a simple invitation and redemption
process with their work or school account, or any email account.
Azure AD B2C is primarily for businesses and developers that create customer-facing apps. With Azure AD B2C,
developers can use Azure AD as the full-featured identity system for their application, while letting customers sign
in with an identity they already have established (like Facebook or Gmail).
The table below gives a detailed comparison.

B2B COLLABORATION CAPABILITIES AZURE AD B2C STAND-ALONE OFFERING

Intended for: Organizations that want to be able to Intended for: Inviting customers of your mobile and web apps,
authenticate users from a partner organization, regardless of whether individuals, institutional or organizational customers
identity provider. into your Azure AD.

Identities supported: Employees with work or school accounts, Identities supported: Consumer users with local application
partners with work or school accounts, or any email address. accounts (any email address or user name) or any supported
Soon to support direct federation. social identity with direct federation.

External users are managed in the same directory as External users are managed in the application directory.
employees, but annotated specially. They can be managed the They're managed separately from the organization’s employee
same way as employees, they can be added to the same and partner directory (if any).
groups, and so on

Single sign-on (SSO) to all Azure AD-connected apps is SSO to customer owned apps within the Azure AD B2C
supported. For example, you can provide access to Office 365 tenants is supported. SSO to Office 365 or to other Microsoft
or on-premises apps, and to other SaaS apps such as SaaS apps is not supported.
Salesforce or Workday.

Partner lifecycle: Managed by the host/inviting organization. Customer lifecycle: Self-serve or managed by the application.

Security policy and compliance: Managed by the host/inviting Security policy and compliance: Managed by the application.
organization (for example, with Conditional Access policies).

Branding: Host/inviting organization’s brand is used. Branding: Managed by application. Typically tends to be
product branded, with the organization fading into the
background.

More info: Blog post, Documentation More info: Product page, Documentation

Next steps
What is Azure AD B2B collaboration?
B2B collaboration user properties
Quickstart: Add guest users to your directory in the
Azure portal
5/16/2019 • 2 minutes to read • Edit Online

You can invite anyone to collaborate with your organization by adding them to your directory as a guest user. Then
you can either send an invitation email that contains a redemption link or send a direct link to an app you want to
share. Guest users can sign in with their own work, school, or social identities.
In this quickstart, you'll add a new guest user to Azure AD, send an invitation, and see what the guest user's
invitation redemption process looks like.
If you don’t have an Azure subscription, create a free account before you begin.

Prerequisites
To complete the scenario in this tutorial, you need:
A role that allows you to create users in your tenant directory, like the Global Administrator role or any of the
limited administrator directory roles.
A valid email account that you can add to your tenant directory, and that you can use to receive the test
invitation email.

Add a new guest user in Azure AD


1. Sign in to the Azure portal as an Azure AD administrator.
2. In the left pane, select Azure Active Directory.
3. Under Manage, select Users.

4. Select New guest user.

5. Under User name, enter the email address of the external user. Under Include a personal message with
the invitation, type a welcome message.
6. Select Invite to automatically send the invitation to the guest user. A notification appears in the upper right
with the message Successfully invited user.
7. After you send the invitation, the user account is automatically added to the directory as a guest.

Assign an app to the guest user


Add the Salesforce app to your test tenant and assign the test guest user to the app.
1. Sign in to the Azure portal as an Azure AD administrator.
2. In the left pane, select Enterprise applications.
3. Select New application.
4. Under Add from the gallery, search for Salesforce, and then select it.
5. Select Add.
6. Under Manage, select Single sign-on, and under Single Sign-on Mode, select Password-based Sign-
on, and click Save.
7. Under Manage, select Users and groups > Add user > Users and groups.
8. Use the search box to search for the test user (if necessary) and select the test user in the list. Then click
Select.
9. Select Assign.

Accept the invitation


Now sign in as the guest user to see the invitation.
1. Sign in to your test guest user's email account.
2. In your inbox, find the "You're invited" email.
3. In the email body, select Get Started. A Review permissions page opens in the browser.

4. Select Accept. The Access Panel opens, which lists the applications the guest user can access.

Clean up resources
When no longer needed, delete the test guest user and the test app.
1. Sign in to the Azure portal as an Azure AD administrator.
2. In the left pane, select Azure Active Directory.
3. Under Manage, select Enterprise applications.
4. Open the application Salesforce, and then select Delete.
5. In the left pane, select Azure Active Directory.
6. Under Manage, select Users.
7. Select the test user, and then select Delete user.

Next steps
In this tutorial, you created a guest user in the Azure portal, and sent an invitation to share apps. Then you viewed
the redemption process from the guest user's perspective and verified that the app appeared on the guest user's
Access Panel. To learn more about adding guest users for collaboration, see Add Azure Active Directory B2B
collaboration users in the Azure portal.
Quickstart: Add a guest user with PowerShell
5/16/2019 • 2 minutes to read • Edit Online

There are many ways you can invite external partners to your apps and services with Azure Active Directory B2B
collaboration. In the previous quickstart, you saw how to add guest users directly in the Azure Active Directory
admin portal. You can also use PowerShell to add guest users, either one at a time or in bulk. In this quickstart,
you’ll use the New -AzureADMSInvitation command to add one guest user to your Azure tenant.
If you don’t have an Azure subscription, create a free account before you begin.

Prerequisites
Install the latest AzureADPreview module
Make sure that you install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview ).
First, check which modules you have installed. Open Windows PowerShell as an elevated user (Run as
administrator), and run the following command:

Get-Module -ListAvailable AzureAD*

If the AzureADPreview module displays with no message indicating there’s a later version, you’re set. Otherwise,
based on the output, do one of the following:
If no results are returned, run the following command to install the AzureADPreview module:

Install-Module AzureADPreview

If only the AzureAD module shows up in the results, run the following commands to install the
AzureADPreview module:

Uninstall-Module AzureAD
Install-Module AzureADPreview

If only the AzureADPreview module shows up in the results, but you receive a message that indicates there's
a later version, run the following commands to update the module:

Uninstall-Module AzureADPreview
Install-Module AzureADPreview

You might receive a prompt that you're installing the module from an untrusted repository. This occurs if you
haven't previously set the PSGallery repository as a trusted repository. Press Y to install the module.
Get a test email account
You need a test email account that you can send the invitation to. The account must be from outside your
organization. You can use any type of account, including a social account such as a gmail.com or outlook.com
address.

Sign in to your tenant


Run the following command to connect to the tenant domain:

Connect-AzureAD -TenantDomain "<Tenant_Domain_Name>"

For example, Connect-AzureAD -TenantDomain "contoso.onmicrosoft.com" .


When prompted, enter your credentials.

Send an invitation
1. To send an invitation to your test email account, run the following PowerShell command (replace "Sanda"
and [email protected] with your test email account name and email address):

New-AzureADMSInvitation -InvitedUserDisplayName "Sanda" -InvitedUserEmailAddress [email protected] -


InviteRedirectURL https://myapps.azure.com -SendInvitationMessage $true

2. The command sends an invitation to the email address specified. Check the output, which should look
similar to the following:

Verify the user exists in the directory


1. To verify that the invited user was added to Azure AD, run the following command:

Get-AzureADUser -Filter "UserType eq 'Guest'"

2. Check the output to make sure the user you invited is listed, with a user principal name (UPN ) in the format
emailaddress#EXT#@domain. For example, sanda_fabrikam.com#EXT#@contoso.onmicrosoft.com, where
contoso.onmicrosoft.com is the organization from which you sent the invitations.
Clean up resources
When no longer needed, you can delete the test user account in the directory. Run the following command to
delete a user account:

Remove-AzureADUser -ObjectId "<UPN>"

For example: Remove-AzureADUser -ObjectId "sanda_fabrikam.com#EXT#@contoso.onmicrosoft.com"

Next steps
In this quickstart, you invited and added a single guest user to your directory using PowerShell. Next, learn how to
invite guest users in bulk using PowerShell.
Tutorial: Bulk invite Azure AD B2B collaboration users
Tutorial: Bulk invite Azure AD B2B collaboration users
(preview)
9/19/2019 • 3 minutes to read • Edit Online

This article describes a public preview feature of Azure Active Directory. For more information about previews, see Supplemental
Terms of Use for Microsoft Azure Previews.

If you use Azure Active Directory (Azure AD ) B2B collaboration to work with external partners, you can invite
multiple guest users to your organization at the same time. In this tutorial, you learn how to use the Azure portal to
send bulk invitations to external users. Specifically, you do the following:
Use Bulk invite users (Preview) to prepare a comma-separated value (.csv) file with the user information and
invitation preferences
Upload the .csv file to Azure AD
Verify the users were added to the directory
If you don’t have Azure Active Directory, create a free account before you begin.

Prerequisites
You need two or more test email accounts that you can send the invitations to. The accounts must be from outside
your organization. You can use any type of account, including social accounts such as gmail.com or outlook.com
addresses.

Invite guest users in bulk


1. Sign in to the Azure portal with an account that is a User administrator in the organization.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Users > Bulk invite.
4. On the Bulk invite users (Preview) page, select Download to get a valid .csv file with invitation
properties.

5. Open the .csv file and add a line for each guest user. Required values are:
Email address to invite - the user who will receive an invitation
Redirection url - the URL to which the invited user is forwarded after accepting the invitation
NOTE
Don't use commas in the Customized invitation message because they'll prevent the message from being parsed
successfully.

6. Save the file.


7. On the Bulk invite users (Preview) page, under Upload your csv file, browse to the file. When you select
the file, validation of the .csv file starts.
8. When the file contents are validated, you’ll see File uploaded successfully. If there are errors, you must fix
them before you can submit the job.
9. When your file passes validation, select Submit to start the Azure bulk operation that adds the invitations.
10. To view the job status, select Click here to view the status of each operation. Or, you can select Bulk
operation results (Preview) in the Activity section. For details about each line item within the the bulk
operation, select the values under the # Success, # Failure, or Total Requests columns. If failures occurred,
the reasons for failure will be listed.

11. When the job completes, you'll see a notification that the bulk operation succeeded.

Verify guest users in the directory


Check to see that the guest users you added exist in the directory either in the Azure portal or by using
PowerShell.
View guest users in the Azure portal
1. Sign in to the Azure portal with an account that is a User administrator in the organization.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Users.
4. Under Show, select Guest users only and verify the users you added are listed.
View guest users with PowerShell
Run the following command:

Get-AzureADUser -Filter "UserType eq 'Guest'"

You should see the users that you invited listed, with a user principal name (UPN ) in the format
emailaddress#EXT#@domain. For example, lstokes_fabrikam.com#EXT#@contoso.onmicrosoft.com, where
contoso.onmicrosoft.com is the organization from which you sent the invitations.

Clean up resources
When no longer needed, you can delete the test user accounts in the directory in the Azure portal on the Users
page by selecting the checkbox next to the guest user and then selecting Delete.
Or you can run the following PowerShell command to delete a user account:

Remove-AzureADUser -ObjectId "<UPN>"

For example: Remove-AzureADUser -ObjectId "lstokes_fabrikam.com#EXT#@contoso.onmicrosoft.com"

Next steps
In this tutorial, you sent bulk invitations to guest users outside of your organization. Next, learn how the invitation
redemption process works.
Learn about the Azure AD B2B collaboration invitation redemption process
Tutorial: Enforce multi-factor authentication for B2B
guest users
6/13/2019 • 4 minutes to read • Edit Online

When collaborating with external B2B guest users, it’s a good idea to protect your apps with multi-factor
authentication (MFA) policies. Then external users will need more than just a user name and password to access
your resources. In Azure Active Directory (Azure AD ), you can accomplish this goal with a Conditional Access
policy that requires MFA for access. MFA policies can be enforced at the tenant, app, or individual guest user level,
the same way that they are enabled for members of your own organization.
Example:

1. An admin or employee at Company A invites a guest user to use a cloud or on-premises application that is
configured to require MFA for access.
2. The guest user signs in with their own work, school, or social identity.
3. The user is asked to complete an MFA challenge.
4. The user sets up MFA with Company A and chooses their MFA option. The user is allowed access to the
application.
In this tutorial, you will:
Test the sign-in experience before MFA setup.
Create a Conditional Access policy that requires MFA for access to a cloud app in your environment. In this
tutorial, we’ll use the Microsoft Azure Management app to illustrate the process.
Use the What If tool to simulate MFA sign-in.
Test your Conditional Access policy.
Clean up the test user and policy.
If you don’t have an Azure subscription, create a free account before you begin.

Prerequisites
To complete the scenario in this tutorial, you need:
Access to Azure AD Premium edition, which includes Conditional Access policy capabilities. To enforce MFA,
you need to create an Azure AD Conditional Access policy. Note that MFA policies are always enforced at your
organization, regardless of whether the partner has MFA capabilities. If you set up MFA for your organization,
you’ll need to make sure you have sufficient Azure AD Premium licenses for your guest users.
A valid external email account that you can add to your tenant directory as a guest user and use to sign in. If
you don't know how to create a guest account, see Add a B2B guest user in the Azure portal.

Create a test guest user in Azure AD


1. Sign in to the Azure portal as an Azure AD administrator.
2. In the left pane, select Azure Active Directory.
3. Under Manage, select Users.
4. Select New guest user.

5. Under User name, enter the email address of the external user. Optionally, include a welcome message.

6. Select Invite to automatically send the invitation to the guest user. A Successfully invited user message
appears.
7. After you send the invitation, the user account is automatically added to the directory as a guest.

Test the sign-in experience before MFA setup


1. Use your test user name and password to sign in to your Azure portal.
2. Note that you’re able to access the Azure portal using just your sign-in credentials. No additional authentication
is required.
3. Sign out.

Create a Conditional Access policy that requires MFA


1. Sign in to your Azure portal as a security administrator or a Conditional Access administrator.
2. In the Azure portal, select Azure Active Directory.
3. On the Azure Active Directory page, in the Security section, select Conditional Access.
4. On the Conditional Access page, in the toolbar on the top, select New policy.
5. On the New page, in the Name textbox, type Require MFA for B2B portal access.
6. In the Assignments section, select Users and groups.
7. On the Users and groups page, choose Select users and groups, and then select All guest users
(preview).

8. Select Done.
9. On the New page, in the Assignments section, select Cloud apps.
10. On the Cloud apps page, choose Select apps, and then choose Select.

11. On the Select page, choose Microsoft Azure Management, and then choose Select.
12. On the Cloud apps page, select Done.
13. On the New page, in the Access controls section, select Grant.
14. On the Grant page, choose Grant access, select the Require multi-factor authentication check box, and
then choose Select.

15. Under Enable policy, select On.

16. Select Create.

Use the What If option to simulate sign-in


1. On the Conditional Access - Policies page, select What If.
2. Select User, choose your test guest user, and then choose Select.

3. Select Cloud apps.


4. On the Cloud apps page, choose Select apps and then click Select. In the applications list, select
Microsoft Azure Management, and then click Select.
5. On the Cloud apps page, select Done.
6. Select What If, and verify that your new policy appears under Evaluation results on the Policies that will
apply tab.

Test your Conditional Access policy


1. Use your test user name and password to sign in to your Azure portal.
2. You should see a request for additional authentication methods. Note that it could take some time for the
policy to take effect.

3. Sign out.

Clean up resources
When no longer needed, remove the test user and the test Conditional Access policy.
1. Sign in to the Azure portal as an Azure AD administrator.
2. In the left pane, select Azure Active Directory.
3. Under Manage, select Users.
4. Select the test user, and then select Delete user.
5. In the left pane, select Azure Active Directory.
6. Under Security, select Conditional Access.
7. In the Policy Name list, select the context menu (…) for your test policy, and then select Delete. Select Yes to
confirm.

Next steps
In this tutorial, you’ve created a Conditional Access policy that requires guest users to use MFA when signing in to
one of your cloud apps. To learn more about adding guest users for collaboration, see Add Azure Active Directory
B2B collaboration users in the Azure portal.
Self-service portal for Azure AD B2B collaboration
sign-up
5/16/2019 • 2 minutes to read • Edit Online

Customers can do a lot with the built-in features that are exposed through the Azure portal and the Application
Access Panel for end users. However, you might need to customize the onboarding workflow for B2B users to fit
your organization’s needs. You can do that with the invitation API.
As an inviting organization, you may not know ahead of time who the individual external collaborators are who
need access to your resources. You need a way for users from partner companies to sign themselves up with a set
of policies that you as the inviting organization controls. This scenario is possible through the APIs. There's a
sample project on GitHub that does just that.
This GitHub project shows how organizations can use the APIs to provide a policy-based, self-service sign-up
capability for your trusted partners, with rules that determine the apps they can access. Partner users can get access
to resources when they need them. They can do this securely, without requiring the inviting organization to
manually onboard them. You can easily deploy the project into an Azure subscription of your choice.

As-is code
This code is made available as a sample to demonstrate usage of the Azure Active Directory B2B invitation API. It
should be customized by your development team or a partner, and should be reviewed before you deploy it in a
production scenario.

Next steps
What is Azure AD B2B collaboration?
Azure AD B2B collaboration licensing
Azure Active Directory B2B collaboration frequently asked questions (FAQ )
Azure Active Directory B2B collaboration code and
PowerShell samples
5/16/2019 • 3 minutes to read • Edit Online

PowerShell example
You can bulk-invite external users to an organization from email addresses that you have stored in a .CSV file.
1. Prepare the .CSV file Create a new CSV file and name it invitations.csv. In this example, the file is saved in
C:\data, and contains the following information:

NAME INVITEDUSEREMAILADDRESS

Gmail B2B Invitee [email protected]

Outlook B2B invitee [email protected]

2. Get the latest Azure AD PowerShell To use the new cmdlets, you must install the updated Azure AD
PowerShell module, which you can download from the Powershell module's release page
3. Sign in to your tenancy

$cred = Get-Credential
Connect-AzureAD -Credential $cred

4. Run the PowerShell cmdlet

$invitations = import-csv C:\data\invitations.csv


$messageInfo = New-Object Microsoft.Open.MSGraph.Model.InvitedUserMessageInfo
$messageInfo.customizedMessageBody = "Hey there! Check this out. I created an invitation through
PowerShell"
foreach ($email in $invitations) {New-AzureADMSInvitation -InvitedUserEmailAddress
$email.InvitedUserEmailAddress -InvitedUserDisplayName $email.Name -InviteRedirectUrl
https://wingtiptoysonline-dev-ed.my.salesforce.com -InvitedUserMessageInfo $messageInfo -
SendInvitationMessage $true}

This cmdlet sends an invitation to the email addresses in invitations.csv. Additional features of this cmdlet include:
Customized text in the email message
Including a display name for the invited user
Sending messages to CCs or suppressing email messages altogether

Code sample
Here we illustrate how to call the invitation API, in "app-only" mode, to get the redemption URL for the resource to
which you are inviting the B2B user. The goal is to send a custom invitation email. The email can be composed with
an HTTP client, so you can customize how it looks and send it through Graph API.

namespace SampleInviteApp
{
using System;
using System.Linq;
using System.Net.Http;
using System.Net.Http.Headers;
using Microsoft.IdentityModel.Clients.ActiveDirectory;
using Newtonsoft.Json;
class Program
{
/// <summary>
/// Microsoft graph resource.
/// </summary>
static readonly string GraphResource = "https://graph.microsoft.com";

/// <summary>
/// Microsoft graph invite endpoint.
/// </summary>
static readonly string InviteEndPoint = "https://graph.microsoft.com/v1.0/invitations";

/// <summary>
/// Authentication endpoint to get token.
/// </summary>
static readonly string EstsLoginEndpoint = "https://login.microsoftonline.com";

/// <summary>
/// This is the tenantid of the tenant you want to invite users to.
/// </summary>
private static readonly string TenantID = "";

/// <summary>
/// This is the application id of the application that is registered in the above tenant.
/// The required scopes are available in the below link.
/// https://developer.microsoft.com/graph/docs/api-reference/v1.0/api/invitation_post
/// </summary>
private static readonly string TestAppClientId = "";

/// <summary>
/// Client secret of the application.
/// </summary>
private static readonly string TestAppClientSecret = @"";

/// <summary>
/// This is the email address of the user you want to invite.
/// </summary>
private static readonly string InvitedUserEmailAddress = @"";

/// <summary>
/// This is the display name of the user you want to invite.
/// </summary>
private static readonly string InvitedUserDisplayName = @"";

/// <summary>
/// Main method.
/// </summary>
/// <param name="args">Optional arguments</param>
static void Main(string[] args)
{
Invitation invitation = CreateInvitation();
SendInvitation(invitation);
}

/// <summary>
/// Create the invitation object.
/// </summary>
/// <returns>Returns the invitation object.</returns>
private static Invitation CreateInvitation()
{
// Set the invitation object.
Invitation invitation = new Invitation();
invitation.InvitedUserDisplayName = InvitedUserDisplayName;
invitation.InvitedUserEmailAddress = InvitedUserEmailAddress;
invitation.InviteRedirectUrl = "https://www.microsoft.com";
invitation.SendInvitationMessage = true;
return invitation;
}

/// <summary>
/// Send the guest user invite request.
/// </summary>
/// <param name="invitation">Invitation object.</param>
private static void SendInvitation(Invitation invitation)
{
string accessToken = GetAccessToken();

HttpClient httpClient = GetHttpClient(accessToken);

// Make the invite call.


HttpContent content = new StringContent(JsonConvert.SerializeObject(invitation));
content.Headers.Add("ContentType", "application/json");
var postResponse = httpClient.PostAsync(InviteEndPoint, content).Result;
string serverResponse = postResponse.Content.ReadAsStringAsync().Result;
Console.WriteLine(serverResponse);
}

/// <summary>
/// Get the HTTP client.
/// </summary>
/// <param name="accessToken">Access token</param>
/// <returns>Returns the Http Client.</returns>
private static HttpClient GetHttpClient(string accessToken)
{
// setup http client.
HttpClient httpClient = new HttpClient();
httpClient.Timeout = TimeSpan.FromSeconds(300);
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer",
accessToken);
httpClient.DefaultRequestHeaders.Add("client-request-id", Guid.NewGuid().ToString());
Console.WriteLine(
"CorrelationID for the request: {0}",
httpClient.DefaultRequestHeaders.GetValues("client-request-id").Single());
return httpClient;
}

/// <summary>
/// Get the access token for our application to talk to microsoft graph.
/// </summary>
/// <returns>Returns the access token for our application to talk to microsoft graph.</returns>
private static string GetAccessToken()
{
string accessToken = null;

// Get the access token for our application to talk to microsoft graph.
try
{
AuthenticationContext testAuthContext =
new AuthenticationContext(string.Format("{0}/{1}", EstsLoginEndpoint, TenantID));
AuthenticationResult testAuthResult = testAuthContext.AcquireTokenAsync(
GraphResource,
new ClientCredential(TestAppClientId, TestAppClientSecret)).Result;
accessToken = testAuthResult.AccessToken;
}
catch (AdalException ex)
{
Console.WriteLine("An exception was thrown while fetching the token: {0}.", ex);
throw;
}

return accessToken;
}
/// <summary>
/// Invitation class.
/// </summary>
public class Invitation
{
/// <summary>
/// Gets or sets display name.
/// </summary>
public string InvitedUserDisplayName { get; set; }

/// <summary>
/// Gets or sets display name.
/// </summary>
public string InvitedUserEmailAddress { get; set; }

/// <summary>
/// Gets or sets a value indicating whether Invitation Manager should send the email to
InvitedUser.
/// </summary>
public bool SendInvitationMessage { get; set; }

/// <summary>
/// Gets or sets invitation redirect URL
/// </summary>
public string InviteRedirectUrl { get; set; }
}
}
}

Next steps
What is Azure AD B2B collaboration?
Azure Active Directory B2B collaboration licensing
guidance
8/29/2019 • 2 minutes to read • Edit Online

With Azure Active Directory (Azure AD ) business-to-business (B2B ) collaboration, you can invite External Users
(or "guest users") to use your paid Azure AD services. Some features are free, but for any paid Azure AD features,
you can invite up to five guest users for each Azure AD edition license that you own for an employee or a non-
guest user in your tenant.

NOTE
Refer to Azure Active Directory pricing for details about Azure AD pricing and B2B collaboration features.

B2B guest user licensing is automatically calculated and reported based on the 1:5 ratio. Currently, it’s not possible
to assign B2B guest user licenses directly to guest users.
Additionally, guest users can use free Azure AD features with no additional licensing requirements. Guest users
have access to free Azure AD features even if you don’t have any paid Azure AD licenses.

Examples: Calculating guest user licenses


Once you determine how many guest users need to access your paid Azure AD services, make sure you have
enough Azure AD paid licenses to cover guest users in the required 1:5 ratio. Here are some examples:
You want to invite 100 guest users to your Azure AD apps or services and provide access management and
provisioning. For 50 of those guest users, you also want to require MFA and Conditional Access, so for those
features you'll need 10 Azure AD Premium P1 licenses. If you plan to use Identity Protection features with your
guest users, you'll need Azure AD Premium P2 licenses in the same 1:5 ratio to cover the guest users.
You want to invite 60 guest users who all require MFA, so you must have at least 12 Azure AD Premium P1
licenses. You have 10 employees with Azure AD Premium P1 licenses, which would allow up to 50 guest users
under the 1:5 licensing ratio. You’ll need to purchase two additional Premium P1 licenses to cover 10 additional
guest users.

Next steps
See the following resources on Azure AD B2B collaboration:
Azure Active Directory pricing
What is Azure AD B2B collaboration?
Azure Active Directory B2B collaboration frequently asked questions (FAQ )
Office 365 external sharing and Azure Active
Directory B2B collaboration
6/7/2019 • 2 minutes to read • Edit Online

External sharing in Office 365 (OneDrive, SharePoint Online, Unified Groups, etc.) and Azure Active Directory
(Azure AD ) B2B collaboration are technically the same thing. All external sharing (except OneDrive/SharePoint
Online), including guests in Office 365 Groups, already uses the Azure AD B2B collaboration invitation APIs for
sharing.

How does Azure AD B2B differ from external sharing in SharePoint


Online?
OneDrive/SharePoint Online has a separate invitation manager. Support for external sharing in
OneDrive/SharePoint Online started before Azure AD developed its support. Over time, OneDrive/SharePoint
Online external sharing has accrued several features and many millions of users who use the product's in-built
sharing pattern. However, there are some subtle differences between how OneDrive/SharePoint Online external
sharing works and how Azure AD B2B collaboration works. You can learn more about OneDrive/SharePoint
Online external sharing in External sharing overview. The process generally differs from Azure AD B2B in these
ways:
OneDrive/SharePoint Online adds users to the directory after users have redeemed their invitations. So,
before redemption, you don't see the user in Azure AD portal. If another site invites a user in the meantime,
a new invitation is generated. However, when you use Azure AD B2B collaboration, users are added
immediately on invitation so that they show up everywhere.
The redemption experience in OneDrive/SharePoint Online looks different from the experience in Azure AD
B2B collaboration. After a user redeems an invitation, the experiences look alike.
Azure AD B2B collaboration invited users can be picked from OneDrive/SharePoint Online sharing dialog
boxes. OneDrive/SharePoint Online invited users also show up in Azure AD after they redeem their
invitations.
The licensing requirements differ. For each paid Azure AD license, you can let up to 5 guest users access
your paid Azure AD features. To learn more about licensing, see Azure AD B2B licensing and "What is an
external user?" in the SharePoint Online external sharing overview.
To manage external sharing in OneDrive/SharePoint Online with Azure AD B2B collaboration, set the
OneDrive/SharePoint Online external sharing setting to Allow sharing only with the external users that
already exist in your organization's directory. Users can go to externally shared sites and pick from external
collaborators that the admin has added. The admin can add the external collaborators through the B2B
collaboration invitation APIs.
After enabling external sharing, the ability to search for existing guest users in the SharePoint Online (SPO ) people
picker is OFF by default to match legacy behavior.
You can enable this feature by using the setting 'ShowPeoplePickerSuggestionsForGuestUsers' at the tenant and
site collection level. You can set the feature using the Set-SPOTenant and Set-SPOSite cmdlets, which allow
members to search all existing guest users in the directory. Changes in the tenant scope do not affect already
provisioned SPO sites.

Next steps
What is Azure AD B2B collaboration?
Adding a B2B collaboration user to a role
Delegate B2B collaboration invitations
Dynamic groups and B2B collaboration
Troubleshooting Azure Active Directory B2B collaboration
Azure Active Directory B2B collaboration invitation
redemption
8/19/2019 • 4 minutes to read • Edit Online

This article describes the ways guest users can access your resources and the consent process they'll encounter. If
you send an invitation email to the guest, the invitation includes a link the guest can redeem to get access to your
app or portal. The invitation email is just one of the ways guests can get access to your resources. As an
alternative, you can add guests to your directory and give them a direct link to the portal or app you want to
share. Regardless of the method they use, guests are guided through a first-time consent process. This process
ensures that your guests agree to privacy terms and accept any terms of use you've set up.
When you add a guest user to your directory, the guest user account has a consent status (viewable in
PowerShell) that’s initially set to PendingAcceptance. This setting remains until the guest accepts your
invitation and agrees to your privacy policy and terms of use. After that, the consent status changes to Accepted,
and the consent pages are no longer presented to the guest.

Redemption through the invitation email


When you add a guest user to your directory by using the Azure portal, an invitation email is sent to the guest in
the process. You can also choose to send invitation emails when you’re using PowerShell to add guest users to
your directory. Here’s a description of the guest’s experience when they redeem the link in the email.
1. The guest receives an invitation email that's sent from Microsoft Invitations.
2. The guest selects Get Started in the email.
3. If the guest doesn't have an Azure AD account, a Microsoft Account (MSA), or an email account in a federated
organization, they're prompted to create an MSA (unless the one-time passcode feature is enabled, which
doesn’t require an MSA).
4. The guest is guided through the consent experience described below.

Redemption through a direct link


As an alternative to the invitation email, you can give a guest a direct link to your app or portal. You first need to
add the guest user to your directory via the Azure portal or PowerShell. Then you can use any of the
customizable ways to deploy applications to users, including direct sign-on links. When a guest uses a direct link
instead of the invitation email, they’ll still be guided through the first-time consent experience.

IMPORTANT
The direct link must be tenant-specific. In other words, it must include a tenant ID or verified domain so the guest can be
authenticated in your tenant, where the shared app is located. A common URL like https://myapps.microsoft.com won’t
work for a guest because it will redirect to their home tenant for authentication. Here are some examples of direct links with
tenant context:
Apps access panel: https://myapps.microsoft.com/?tenantid=<tenant id>
Apps access panel for a verified domain: https://myapps.microsoft.com/<verified domain>
Azure portal: https://portal.azure.com/<tenant id>
Individual app: see how to use a direct sign-on link

There are some cases where the invitation email is recommended over a direct link. If these special cases are
important to your organization, we recommend that you invite users by using methods that still send the
invitation email:
The user doesn’t have an Azure AD account, an MSA, or an email account in a federated organization. Unless
you're using the one-time passcode feature, the guest needs to redeem the invitation email to be guided
through the steps for creating an MSA.
Sometimes the invited user object may not have an email address because of a conflict with a contact object
(for example, an Outlook contact object). In this case, the user must click the redemption URL in the invitation
email.
The user may sign in with an alias of the email address that was invited. (An alias is an additional email
address associated with an email account.) In this case, the user must click the redemption URL in the
invitation email.

Consent experience for the guest


When a guest signs in to access resources in a partner organization for the first time, they're guided through the
following pages.
1. The guest reviews the Review permissions page describing the inviting organization's privacy statement.
A user must Accept the use of their information in accordance to the inviting organization's privacy
policies to continue.

NOTE
For information about how you as a tenant administrator can link to your organization's privacy statement, see
How-to: Add your organization's privacy info in Azure Active Directory.

2. If terms of use are configured, the guest opens and reviews the terms of use, and then selects Accept.
NOTE
You can configure see terms of use in Manage > Organizational relationships > Terms of use.

3. Unless otherwise specified, the guest is redirected to the Apps access panel, which lists the applications the
guest can access.

In your directory, the guest's Invitation accepted value changes to Yes. If an MSA was created, the guest’s
Source shows Microsoft Account. For more information about guest user account properties, see Properties of
an Azure AD B2B collaboration user.

Next steps
What is Azure AD B2B collaboration?
Add Azure Active Directory B2B collaboration users in the Azure portal
How do information workers add B2B collaboration users to Azure Active Directory?
Add Azure Active Directory B2B collaboration users by using PowerShell
Leave an organization as a guest user
The elements of the B2B collaboration invitation
email - Azure Active Directory
5/16/2019 • 3 minutes to read • Edit Online

Invitation emails are a critical component to bring partners on board as B2B collaboration users in Azure AD. You
can use them to increase the recipient's trust. you can add legitimacy and social proof to the email, to make sure
the recipient feels comfortable with selecting the Get Started button to accept the invitation. This trust is a key
means to reduce sharing friction. And you also want to make the email look great!
Explaining the email
Let's look at a few elements of the email so you know how best to use their capabilities.
Subject
The subject of the email follows the following pattern: You're invited to the <tenantname> organization
From address
We use a LinkedIn-like pattern for the From address. You should be clear who the inviter is and from which
company, and also clarify that the email is coming from a Microsoft email address. The format is: Microsoft
Invitations [email protected] or <Display name of inviter> from <tenantname> (via Microsoft)
[email protected].
Reply To
The reply-to email is set to the inviter's email when available, so that replying to the email sends an email back to
the inviter.
Branding
The invitation emails from your tenant use the company branding that you may have set up for your tenant. If you
want to take advantage of this capability, here are the details on how to configure it. The banner logo appears in
the email. Follow the image size and quality instructions here for best results. In addition, the company name also
shows up in the call to action.
Call to action
The call to action consists of two parts: explaining why the recipient has received the mail and what the recipient is
being asked to do about it.
The "why" section can be addressed using the following pattern: You've been invited to access applications
in the <tenantname> organization
And the "what you're being asked to do" section is indicated by the presence of the Get Started button.
When the recipient has been added without the need for invitations, this button doesn't show up.
Inviter's information
The inviter's display name is included in the email. And in addition, if you've set up a profile picture for your Azure
AD account, the inviting email will include that picture as well. Both are intended to increase your recipient's
confidence in the email.
If you haven't yet set up your profile picture, an icon with the inviter's initials in place of the picture is shown:

Body
The body contains the message that the inviter composes when inviting a guest user to the directory, group, or app
or by using the invitation API. It is a text area, so it does not process HTML tags for security reasons.
Footer section
The footer contains the Microsoft company brand and lets the recipient know if the email was sent from an
unmonitored alias.
Special cases:
The inviter doesn't have an email address in the inviting tenancy

The recipient doesn't need to redeem the invitation


How the language is determined
The language presented to the guest user in the invitation email is determined by the following settings. These
settings are listed in order of precedence. If a setting isn’t configured, the next setting in the list determines the
language.
The messageLanguage property of the invitedUserMessageInfo object if the Create invitation API is used
The preferredLanguage property specified in the guest's user object
The Notification language set in the properties of the guest user’s home tenant (for Azure AD tenants only)
The Notification language set in the properties of the resource tenant
If none of these settings are configured, the language defaults to English (US ).

Next steps
See the following articles on Azure AD B2B collaboration:
What is Azure AD B2B collaboration
How do Azure Active Directory admins add B2B collaboration users?
How do information workers add B2B collaboration users?
B2B collaboration invitation redemption
Add B2B collaboration users without an invitation
Properties of an Azure Active Directory B2B
collaboration user
5/16/2019 • 5 minutes to read • Edit Online

This article describes the properties and states of the B2B guest user object in Azure Active Directory (Azure AD )
before and after invitation redemption. An Azure AD business-to-business (B2B ) collaboration user is a user with
UserType = Guest. This guest user typically is from a partner organization and has limited privileges in the inviting
directory, by default.
Depending on the inviting organization's needs, an Azure AD B2B collaboration user can be in one of the following
account states:
State 1: Homed in an external instance of Azure AD and represented as a guest user in the inviting
organization. In this case, the B2B user signs in by using an Azure AD account that belongs to the invited
tenant. If the partner organization doesn't use Azure AD, the guest user in Azure AD is still created. The
requirements are that they redeem their invitation and Azure AD verifies their email address. This
arrangement is also called a just-in-time (JIT) tenancy or a "viral" tenancy.
State 2: Homed in a Microsoft or other account and represented as a guest user in the host organization. In
this case, the guest user signs in with a Microsoft account or a social account (google.com or similar). The
invited user's identity is created as a Microsoft account in the inviting organization’s directory during offer
redemption.
State 3: Homed in the host organization's on-premises Active Directory and synced with the host
organization's Azure AD. You can use Azure AD Connect to sync the partner accounts to the cloud as Azure
AD B2B users with UserType = Guest. See Grant locally-managed partner accounts access to cloud
resources.
State 4: Homed in the host organization's Azure AD with UserType = Guest and credentials that the host
organization manages.

Now, let's see what an Azure AD B2B collaboration user looks like in Azure AD.
Before invitation redemption
State 1 and State 2 accounts are the result of inviting guest users to collaborate by using the guest users' own
credentials. When the invitation is initially sent to the guest user, an account is created in your directory. This
account doesn’t have any credentials associated with it because authentication is performed by the guest user's
identity provider. The Source property for the guest user account in your directory is set to Invited user.

After invitation redemption


After the guest user accepts the invitation, the Source property is updated based on the guest user’s identity
provider.
For guest users in State 1, the Source is External Azure Active Directory.
For guest users in State 2, the Source is Microsoft Account.

For guest users in State 3 and State 4, the Source property is set to Azure Active Directory or Windows Server
Active Directory, as described in the next section.

Key properties of the Azure AD B2B collaboration user


UserType
This property indicates the relationship of the user to the host tenancy. This property can have two values:
Member: This value indicates an employee of the host organization and a user in the organization's payroll.
For example, this user expects to have access to internal-only sites. This user is not considered an external
collaborator.
Guest: This value indicates a user who isn't considered internal to the company, such as an external
collaborator, partner, or customer. Such a user isn't expected to receive a CEO's internal memo or receive
company benefits, for example.

NOTE
The UserType has no relation to how the user signs in, the directory role of the user, and so on. This property simply
indicates the user's relationship to the host organization and allows the organization to enforce policies that depend
on this property.

Source
This property indicates how the user signs in.
Invited User: This user has been invited but has not yet redeemed an invitation.
External Active Directory: This user is homed in an external organization and authenticates by using an
Azure AD account that belongs to the other organization. This type of sign-in corresponds to State 1.
Microsoft account: This user is homed in a Microsoft account and authenticates by using a Microsoft
account. This type of sign-in corresponds to State 2.
Windows Server Active Directory: This user is signed in from on-premises Active Directory that belongs to
this organization. This type of sign-in corresponds to State 3.
Azure Active Directory: This user authenticates by using an Azure AD account that belongs to this
organization. This type of sign-in corresponds to State 4.

NOTE
Source and UserType are independent properties. A value of Source does not imply a particular value for UserType.

Can Azure AD B2B users be added as members instead of guests?


Typically, an Azure AD B2B user and guest user are synonymous. Therefore, an Azure AD B2B collaboration user is
added as a user with UserType = Guest by default. However, in some cases, the partner organization is a member
of a larger organization to which the host organization also belongs. If so, the host organization might want to treat
users in the partner organization as members instead of guests. Use the Azure AD B2B Invitation Manager APIs to
add or invite a user from the partner organization to the host organization as a member.

Filter for guest users in the directory


Convert UserType
It's possible to convert UserType from Member to Guest and vice-versa by using PowerShell. However, the
UserType property represents the user's relationship to the organization. Therefore, you should change this
property only if the relationship of the user to the organization changes. If the relationship of the user changes,
should the user principal name (UPN ) change? Should the user continue to have access to the same resources?
Should a mailbox be assigned? We don't recommend changing the UserType by using PowerShell as an atomic
activity. Also, in case this property becomes immutable by using PowerShell, we don't recommend taking a
dependency on this value.

Remove guest user limitations


There may be cases where you want to give your guest users higher privileges. You can add a guest user to any role
and even remove the default guest user restrictions in the directory to give a user the same privileges as members.
It's possible to turn off the default limitations so that a guest user in the company directory has the same
permissions as a member user.
Can I make guest users visible in the Exchange Global Address List?
Yes. By default, guest objects aren't visible in your organization's global address list, but you can use Azure Active
Directory PowerShell to make them visible. For details, see Can I make guest objects visible in the global
address list? in Manage guest access in Office 365 Groups.

Next steps
What is Azure AD B2B collaboration?
B2B collaboration user tokens
B2B collaboration user claims mapping
B2B collaboration user claims mapping in Azure
Active Directory
5/16/2019 • 2 minutes to read • Edit Online

Azure Active Directory (Azure AD ) supports customizing the claims that are issued in the SAML token for B2B
collaboration users. When a user authenticates to the application, Azure AD issues a SAML token to the app that
contains information (or claims) about the user that uniquely identifies them. By default, this includes the user's
user name, email address, first name, and last name.
In the Azure portal, you can view or edit the claims that are sent in the SAML token to the application. To access
the settings, select Azure Active Directory > Enterprise applications > the application that's configured for
single sign-on > Single sign-on. See the SAML token settings in the User Attributes section.

There are two possible reasons why you might need to edit the claims that are issued in the SAML token:
1. The application requires a different set of claim URIs or claim values.
2. The application requires the NameIdentifier claim to be something other than the user principal name
(UPN ) that's stored in Azure AD.

For information about how to add and edit claims, see Customizing claims issued in the SAML token for
enterprise applications in Azure Active Directory.
For B2B collaboration users, mapping NameID and UPN cross-tenant are prevented for security reasons.

Next steps
For information about B2B collaboration user properties, see Properties of an Azure Active Directory B2B
collaboration user.
For information about user tokens for B2B collaboration users, see Understand user tokens in Azure AD B2B
collaboration.
Understand user tokens in Azure AD B2B
collaboration
5/16/2019 • 2 minutes to read • Edit Online

If you want to know what the token looks like for a B2B collaboration user, here are the bearer token details and
token content for an Azure Active Directory (Azure AD ) guest and a Microsoft account guest in the resource
tenant (for tenantid 04dcc6ab-388a-4559-b527-fbec656300ea). To see the JSON Web Token (JWT) contents, use
https://jwt.io/ or https://jwt.ms/.

Azure AD guest token


Authorization: Bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ilk0dWVLMm9hSU5RaVFiNVlFQlNZVnlEY3BBVSIsImtpZCI6Ilk0dWVLMm9hSU5RaV
FiNVlFQlNZVnlEY3BBVSJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0LyIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV
0LzA0ZGNjNmFiLTM4OGEtNDU1OS1iNTI3LWZiZWM2NTYzMDBlYS8iLCJpYXQiOjE0ODQ4MDM5MTgsIm5iZiI6MTQ4NDgwMzkxOCwiZXhwIjoxN
Dg0ODA3ODE4LCJhY3IiOiIxIiwiYWlvIjoiQVFBQkFBRUFBQURSTllSUTNkaFJTcm0tNEstYWRwQ0pJNWNncGtYQ0VOTHdnN1Z1emhFQURIajN
OOWNIMzhRWGFBakhrYUtPRFhneWJpcnVRYVhpa3RZZ3I2M0xMQTVTVDlEeXV2dEtQSUdlXzJpVFRhdjNqSkxuTlRSZ2JWRFpwckhSaEtZbWl5R
WdBQSIsImFsdHNlY2lkIjoiNTo6MTAwMzAwMDA4MDFCQUZDNyIsImFtciI6WyJwd2QiLCJyc2EiXSwiYXBwaWQiOiJjNDRiNDA4My0zYmIwLTQ
5YzEtYjQ3ZC05NzRlNTNjYmRmM2MiLCJhcHBpZGFjciI6IjIiLCJlX2V4cCI6MTA4MDAsImVtYWlsIjoicmFqZXNiQG1pY3Jvc29mdC5jb20iL
CJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaW5fY29ycCI6InR
ydWUiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTk1IiwibmFtZSI6InJhamVzaCIsIm9pZCI6IjA1ODAyY2M1LTgxMWUtNDZiZC1iMWI2LTU5NDZlN
jY4ODIyZiIsInBsYXRmIjoiMyIsInB1aWQiOiIxMDAzM0ZGRjlEOEY5OTUzIiwic2NwIjoidXNlcl9pbXBlcnNvbmF0aW9uIiwic3ViIjoiS1d
3QnVCNk5ROU5UYmpoSUI1OHEwM2FlQVl6cEk2TWxiMkpncGk1aV9ITSIsInRpZCI6IjA0ZGNjNmFiLTM4OGEtNDU1OS1iNTI3LWZiZWM2NTYzM
DBlYSIsInVuaXF1ZV9uYW1lIjoicmFqZXNiQG1pY3Jvc29mdC5jb20iLCJ2ZXIiOiIxLjAifQ.Vllr1hGXpBlpXDBKRHHYbMr_1_DwKNY3eCOb
BOfEaxJirwqujqCZodPrAkIOJlFYyhkILyHZQUi_D1w7XoPsd6U4GQlgOoFfzbye-
P_NdRFabHMlv32gCgHz1xo11aPP453EiwwG5OHnWaHYLBpuqi3sNeKx06xbTFj07HmADDaR4aM0jwy031d6GkD0LdU-Xkazi5-
h8parVRLOkkLZA0oxMFoxl_-VHr1hOzxCkbWgRoug4t97161i5tGil99CcpJ6NK8uQld7TveC40sjJ735Sksn-
Uq_NZcJuXCEVsH0xK5evaeFBFSEqACXjKTvYkJWtAx8Kr8yWZAcEg0YMQ

Microsoft account guest token


Authorization: Bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ilk0dWVLMm9hSU5RaVFiNVlFQlNZVnlEY3BBVSIsImtpZCI6Ilk0dWVLMm9hSU5RaV
FiNVlFQlNZVnlEY3BBVSJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0LyIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV
0LzA0ZGNjNmFiLTM4OGEtNDU1OS1iNTI3LWZiZWM2NTYzMDBlYS8iLCJpYXQiOjE0ODQ4MDMwNjEsIm5iZiI6MTQ4NDgwMzA2MSwiZXhwIjoxN
Dg0ODA2OTYxLCJhY3IiOiIxIiwiYWlvIjoiQVFBQkFBRUFBQURSTllSUTNkaFJTcm0tNEstYWRwQ0pEeEd4a3lUdmJ2d1RoSHJnTEdPaGZEbTA
1aXJndC1lR1d3YTl5QUZQQTJQc19nZHF2bHQ1X1AtaDhrT2IwdUdza3dyYklBbUhvMEtRM005N2ZCVlRtdzRKY0NfaFVkWW1PZ25QYVlOY1BRQ
XBIYmFMcUlaZGhaRXhtQVZJeXFmaElBQSIsImFsdHNlY2lkIjoiMTpsaXZlLmNvbTowMDAzMDAwMEEwNzBCOTYyIiwiYW1yIjpbInB3ZCJdLCJ
hcHBpZCI6ImM0NGI0MDgzLTNiYjAtNDljMS1iNDdkLTk3NGU1M2NiZGYzYyIsImFwcGlkYWNyIjoiMiIsImVfZXhwIjoxMDgwMCwiZW1haWwiO
iJiYXNhcmFqZXNoQGxpdmUuY29tIiwiZmFtaWx5X25hbWUiOiJiYXNhIiwiZ2l2ZW5fbmFtZSI6InJhamVzaCIsImlkcCI6ImxpdmUuY29tIiw
iaXBhZGRyIjoiMTY3LjIyMC4xLjE5NSIsIm5hbWUiOiJiYXNhcmFqZXNoIiwib2lkIjoiMjU0NmU3NDEtNmZjNi00ZDI0LTg2NTQtZjkyNDc5M
zI0ZjM3IiwicGxhdGYiOiIzIiwicHVpZCI6IjEwMDMzRkZGOURBQjk2NDYiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiI4Y2N
5OEh4cmE5UTl2aGdYOXhBODFBeWJEV3dsVmxjXzRBZVJYZ2lzamM4IiwidGlkIjoiMDRkY2M2YWItMzg4YS00NTU5LWI1MjctZmJlYzY1NjMwM
GVhIiwidW5pcXVlX25hbWUiOiJsaXZlLmNvbSNiYXNhcmFqZXNoQGxpdmUuY29tIiwidmVyIjoiMS4wIn0.LSIBlJpElXpsGXOGaFINW-
jOBHsI0Dxe3oX-
YIEsccegDCspl6UnRjpwzs0nBL09B4N0oqLd7ZwXZAQURpgaAFnWvROxkIGpNTE_ppSKU1suud8keG5VnTEu82em95G1_c_eW1nOemPvbADCC8
h08p2wxNm8QyEhmYqauN6qYbeqOnioRERXO3zOPg8nSXFcGPhvumJ_BW8XKnW4zLdhK78c3PgynPnwtIm08SksMRDzGMgUc9RK1bpPQtgX8iFQ
ByEljf5cuE_h_e1Nr5Y4StrhS3JCiQLTYZ727YY-lSm5DERiQrt7MkP5BHprEmSByofSvACj5TmVdqBFUjobuA

Next steps
What is Azure AD B2B collaboration?
B2B collaboration user properties
B2B collaboration user claims mapping
Conditional Access for B2B collaboration users
7/19/2019 • 3 minutes to read • Edit Online

Multi-factor authentication for B2B users


With Azure AD B2B collaboration, organizations can enforce multi-factor authentication (MFA) policies for B2B
users. These policies can be enforced at the tenant, app, or individual user level, the same way that they are
enabled for full-time employees and members of the organization. MFA policies are enforced at the resource
organization.
Example:
1. Admin or information worker in Company A invites user from company B to an application Foo in company A.
2. Application Foo in company A is configured to require MFA on access.
3. When the user from company B attempts to access app Foo in the company A tenant, they are asked to
complete an MFA challenge.
4. The user can set up their MFA with company A, and chooses their MFA option.
5. This scenario works for any identity (Azure AD or MSA, for example, if users in Company B authenticate using
social ID )
6. Company A must have sufficient Premium Azure AD licenses that support MFA. The user from company B
consumes this license from company A.
The inviting tenancy is always responsible for MFA for users from the partner organization, even if the partner
organization has MFA capabilities.
Setting up MFA for B2B collaboration users
To discover how easy it is to set up MFA for B2B collaboration users, see how in the following video:

B2B users MFA experience for offer redemption


Check out the following animation to see the redemption experience:

MFA reset for B2B collaboration users


Currently, the admin can require B2B collaboration users to proof up again only by using the following
PowerShell cmdlets:
1. Connect to Azure AD

$cred = Get-Credential
Connect-MsolService -Credential $cred

2. Get all users with proof up methods

Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e=


{($_.StrongAuthenticationMethods).MethodType}}

Here is an example:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e=
{($_.StrongAuthenticationMethods).MethodType}}

3. Reset the MFA method for a specific user to require the B2B collaboration user to set proof-up methods
again. Example:

Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@


WoodGroveAzureAD.onmicrosoft.com

Why do we perform MFA at the resource tenancy?


In the current release, MFA is always in the resource tenancy, for reasons of predictability. For example, let’s say a
Contoso user (Sally) is invited to Fabrikam and Fabrikam has enabled MFA for B2B users.
If Contoso has MFA policy enabled for App1 but not App2, then if we look at the Contoso MFA claim in the token,
we might see the following issue:
Day 1: A user has MFA in Contoso and is accessing App1, then no additional MFA prompt is shown in
Fabrikam.
Day 2: The user has accessed App 2 in Contoso, so now when accessing Fabrikam, they must register for
MFA there.
This process can be confusing and could lead to drop in sign-in completions.
Moreover, even if Contoso has MFA capability, it is not always the case the Fabrikam would trust the Contoso
MFA policy.
Finally, resource tenant MFA also works for MSAs and social IDs and for partner orgs that do not have MFA set
up.
Therefore, the recommendation for MFA for B2B users is to always require MFA in the inviting tenant. This
requirement could lead to double MFA in some cases, but whenever accessing the inviting tenant, the end-users
experience is predictable: Sally must register for MFA with the inviting tenant.
Device -based, location-based, and risk-based Conditional Access for B2B users
When Contoso enables device-based Conditional Access policies for their corporate data, access is prevented from
devices that are not managed by Contoso and not compliant with the Contoso device policies.
If the B2B user’s device isn't managed by Contoso, access of B2B users from the partner organizations is blocked
in whatever context these policies are enforced. However, Contoso can create exclusion lists containing specific
partner users to exclude them from the device-based Conditional Access policy.
Mobile application management policies for B2B
Conditional Access app protection policies cannot be applied to B2B users because the inviting organization has
no visibility into the B2B user's home organization.
Location-based Conditional Access for B2B
Location-based Conditional Access policies can be enforced for B2B users if the inviting organization is able to
create a trusted IP address range that defines their partner organizations.
Risk-based Conditional Access for B2B
Currently, risk-based sign-in policies cannot be applied to B2B users because the risk evaluation is performed at
the B2B user’s home organization.

Next steps
See the following articles on Azure AD B2B collaboration:
What is Azure AD B2B collaboration?
Azure AD B2B collaboration licensing
Azure Active Directory B2B collaboration frequently asked questions (FAQ )
Azure Active Directory B2B collaboration for hybrid
organizations
5/16/2019 • 2 minutes to read • Edit Online

Azure Active Directory (Azure AD ) B2B collaboration makes it easy for you to give your external partners access to
apps and resources in your organization. This is true even in a hybrid configuration where you have both on-
premises and cloud-based resources. It doesn’t matter if you currently manage external partner accounts locally in
your on-premises identity system, or if you manage the external accounts in the cloud as Azure AD B2B users. You
can now grant these users access to resources in either location, using the same sign-in credentials for both
environments.

Grant B2B users in Azure AD access to your on-premises apps


If your organization uses Azure AD B2B collaboration capabilities to invite guest users from partner organizations
to your Azure AD, you can now provide these B2B users access to on-premises apps.
For apps that use SAML -based authentication, you can make these apps available to B2B users through the Azure
portal, using Azure AD Application Proxy for authentication.
For apps that use Integrated Windows Authentication (IWA) with Kerberos constrained delegation (KCD ), you also
use Azure AD Proxy for authentication. However, for authorization to work, a user object is required in the on-
premises Windows Server Active Directory. There are two methods you can use to create local user objects that
represent your B2B guest users.
You can use Microsoft Identity Manager (MIM ) 2016 SP1 and the MIM management agent for Microsoft
Graph.
You can use a PowerShell script. (This solution does not require MIM.)
For details about how to implement these solutions, see Grant B2B users in Azure AD access to your on-premises
applications.

Grant locally-managed partner accounts access to cloud resources


Before Azure AD, organizations with on-premises identity systems have traditionally managed partner accounts in
their on-premises directory. If you’re such an organization, you want to make sure that your partners continue to
have access as you move your apps and other resources to the cloud. Ideally, you want these users to use the same
set of credentials to access both cloud and on-premises resources.
We now offer methods where you can use Azure AD Connect to sync these local accounts to the cloud as "guest
users," where the accounts behave just like Azure AD B2B users.
To help protect your company data, you can control access to just the right resources, and configure authorization
policies that treat these guest users differently from your employees.
For implementation details, see Grant locally-managed partner accounts access to cloud resources using Azure AD
B2B collaboration.

Next steps
Grant B2B users in Azure AD access to your on-premises applications
Grant locally-managed partner accounts access to cloud resources using Azure AD B2B collaboration
Limitations of Azure AD B2B collaboration
6/13/2019 • 2 minutes to read • Edit Online

Azure Active Directory (Azure AD ) B2B collaboration is currently subject to the limitations described in this article.

Possible double multi-factor authentication


With Azure AD B2B, you can enforce multi-factor authentication at the resource organization (the inviting
organization). The reasons for this approach are detailed in Conditional Access for B2B collaboration users. If a
partner already has multi-factor authentication set up and enforced, their users might have to perform the
authentication once in their home organization and then again in yours.

Instant-on
In the B2B collaboration flows, we add users to the directory and dynamically update them during invitation
redemption, app assignment, and so on. The updates and writes ordinarily happen in one directory instance and
must be replicated across all instances. Replication is completed once all instances are updated. Sometimes when
the object is written or updated in one instance and the call to retrieve this object is to another instance, replication
latencies can occur. If that happens, refresh or retry to help. If you are writing an app using our API, then retries
with some back-off is a good, defensive practice to alleviate this issue.

Azure AD directories
Azure AD B2B is subject to Azure AD service directory limits. For details about the number of directories a user
can create and the number of directories to which a user or guest user can belong, see Azure AD service limits and
restrictions.

National clouds
National clouds are physically isolated instances of Azure. B2B collaboration is not supported across national cloud
boundaries. For example, if your Azure tenant is in the public, global cloud, you can't invite a user whose account is
in a national cloud. To collaborate with the user, ask them for another email address or create a member user
account for them in your directory.

Next steps
See the following articles on Azure AD B2B collaboration:
What is Azure AD B2B collaboration?
Delegate B2B collaboration invitations
Enable B2B external collaboration and manage who
can invite guests
5/16/2019 • 2 minutes to read • Edit Online

This article describes how to enable Azure Active Directory (Azure AD ) B2B collaboration and determine who can
invite guests. By default, all users and guests in your directory can invite guests even if they're not assigned to an
admin role. External collaboration settings let you turn guest invitations on or off for different types of users in
your organization. You can also delegate invitations to individual users by assigning roles that allow them to invite
guests.

Configure B2B external collaboration settings


With Azure AD B2B collaboration, a tenant admin can set the following invitation policies:
Turn off invitations
Only admins and users in the Guest Inviter role can invite
Admins, the Guest Inviter role, and members can invite
All users, including guests, can invite
By default, all users, including guests, can invite guest users.
To configure external collaboration settings:
1. Sign in to the Azure portal as a tenant administrator.
2. Select Azure Active Directory > Users > User settings.
3. Under External users, select Manage external collaboration settings.

NOTE
The External collaboration settings are also available from the Organizational relationships page. In Azure
Active Directory, under Manage, go to Organizational relationships > Settings.

4. On the External collaboration settings page, choose the policies you want to enable.
Guest users permissions are limited: This policy determines permissions for guests in your directory. Select
Yes to block guests from certain directory tasks, like enumerating users, groups, or other directory resources.
Select No to give guests the same access to directory data as regular users in your directory.
Admins and users in the guest inviter role can invite: To allow admins and users in the "Guest Inviter" role
to invite guests, set this policy to Yes.
Members can invite: To allow non-admin members of your directory to invite guests, set this policy to Yes.
Guests can invite: To allow guests to invite other guests, set this policy to Yes.
Enable Email One-Time Passcode for guests (Preview): For more information about the one-time
passcode feature, see Email one-time passcode authentication (preview ).
Collaboration restrictions: For more information about allowing or blocking invitations to specific domains,
see Allow or block invitations to B2B users from specific organizations.

Assign the Guest Inviter role to a user


With the Guest Inviter role, you can give individual users the ability to invite guests without assigning them a
global administrator or other admin role. Assign the Guest inviter role to individuals. Then make sure you set
Admins and users in the guest inviter role can invite to Yes.
Here's an example that shows how to use PowerShell to add a user to the Guest Inviter role:

Add-MsolRoleMember -RoleObjectId 95e79109-95c0-4d8e-aee3-d01accf2d47b -RoleMemberEmailAddress


<RoleMemberEmailAddress>

Next steps
See the following articles on Azure AD B2B collaboration:
What is Azure AD B2B collaboration?
Add B2B collaboration guest users without an invitation
Adding a B2B collaboration user to a role
Add Azure Active Directory B2B collaboration users
in the Azure portal
9/16/2019 • 4 minutes to read • Edit Online

As a user who is assigned any of the limited administrator directory roles, you can use the Azure portal to invite
B2B collaboration users. You can invite guest users to the directory, to a group, or to an application. After you
invite a user through any of these methods, the invited user's account is added to Azure Active Directory (Azure
AD ), with a user type of Guest. The guest user must then redeem their invitation to access resources. An
invitation of a user does not expire.
After you add a guest user to the directory, you can either send the guest user a direct link to a shared app, or the
guest user can click the redemption URL in the invitation email. For more information about the redemption
process, see B2B collaboration invitation redemption.

IMPORTANT
You should follow the steps in How-to: Add your organization's privacy info in Azure Active Directory to add the URL of
your organization's privacy statement. As part of the first time invitation redemption process, an invited user must consent
to your privacy terms to continue.

Before you begin


Make sure your organization's external collaboration settings are configured such that you're allowed to invite
guests. By default, all users and admins can invite guests. But your organization's external collaboration policies
might be configured to prevent certain types of users or admins from inviting guests. To find out how to view
and set these policies, see Enable B2B external collaboration and manage who can invite guests.

Add guest users to the directory


To add B2B collaboration users to the directory, follow these steps:
1. Sign in to the Azure portal as a user who is assigned a limited administrator directory role or the Guest
Inviter role.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Users.
4. Select New guest user.
NOTE
The New guest user option is also available on the Organizational relationships page. In Azure Active
Directory, under Manage, select Organizational relationships.

5. Under User name, enter the email address of the external user. Optionally, include a welcome message.
For example:

NOTE
Group email addresses aren’t supported; enter the email address for an individual. Also, some email providers allow
users to add a plus symbol (+) and additional text to their email addresses to help with things like inbox filtering.
However, Azure AD doesn’t currently support plus symbols in email addresses. To avoid delivery issues, omit the
plus symbol and any characters following it up to the @ symbol.

6. Select Invite to automatically send the invitation to the guest user.


After you send the invitation, the user account is automatically added to the directory as a guest.

Add guest users to a group


If you need to manually add B2B collaboration users to a group, follow these steps:
1. Sign in to the Azure portal as an Azure AD administrator.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Groups.
4. Select a group (or click New group to create a new one). It's a good idea to include in the group description
that the group contains B2B guest users.
5. Select Members.
6. Do one of the following:
If the guest user already exists in the directory, search for the B2B user. Select the user, and then
click Select to add the user to the group.
If the guest user does not already exist in the directory, invite them to the group by typing their
email address in the search box, typing an optional personal message, and then clicking Select. The
invitation automatically goes out to the invited user.

You can also use dynamic groups with Azure AD B2B collaboration. For more information, see Dynamic groups
and Azure Active Directory B2B collaboration.

Add guest users to an application


To add B2B collaboration users to an application, follow these steps:
1. Sign in to the Azure portal as an Azure AD administrator.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Enterprise applications > All applications.
4. Select the application to which you want to add guest users.
5. On the application's dashboard, select Total Users to open the Users and groups pane.

6. Select Add user.


7. Under Add Assignment, select User and groups.
8. Do one of the following:
If the guest user already exists in the directory, search for the B2B user. Select the user, clickSelect,
and then click Assign to add the user to the app.
If the guest user does not already exist in the directory, under Select member or invite an
external user, type the user's email address. In the message box, type an optional personal
message. Under the message box, click Invite.
Click Select, and then click Assign to add the user to the app. An invitation automatically goes out
to the invited user.
9. The guest user appears in the application's Users and groups list with the assigned role of Default
Access. If you want to change the role, do the following:
Select the guest user, and then select Edit.
Under Edit Assignment, click Select Role, and select the role you want to assign to the selected user.
Click Select.
Click Assign.

Resend invitations to guest users


If a guest user has not yet redeemed their invitation, you can resend the invitation email.
1. Sign in to the Azure portal as an Azure AD administrator.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Users.
4. Select the user account.
5. Under Manage, select Profile.
6. If the user has not yet accepted the invitation, a Resend invitation option is available. Select this button
to resend.

NOTE
If you resend an invitation that originally directed the user to a specific app, understand that the link in the new invitation
takes the user to the top-level Access Panel instead.

Next steps
To learn how non-Azure AD admins can add B2B guest users, see How do information workers add B2B
collaboration users?
For information about the invitation email, see The elements of the B2B collaboration invitation email.
How users in your organization can invite guest users
to an app
5/16/2019 • 4 minutes to read • Edit Online

After a guest user has been added to the directory in Azure AD, an application owner can send the guest user a
direct link to the app they want to share. Azure AD admins can also set up self-service management for gallery or
SAML -based apps in their Azure AD tenant. This way, application owners can manage their own guest users, even
if the guest users haven’t been added to the directory yet. When an app is configured for self-service, the
application owner uses their Access Panel to invite a guest user to an app or add a guest user to a group that has
access to the app. Self-service app management for gallery and SAML -based apps requires some initial setup by
an admin. The following is a summary of the setup steps (for more detailed instructions, see Prerequisites later on
this page):
Enable self-service group management for your tenant
Create a group to assign to the app and make the user an owner
Configure the app for self-service and assign the group to the app

NOTE
This article describes how to set up self-service management for gallery and SAML-based apps that you’ve added to your
Azure AD tenant. You can also set up self-service Office 365 groups so your users can manage access to their own Office
365 groups. For more ways users can share Office files and apps with guest users, see Guest access in Office 365 groups and
Share SharePoint files or folders.

Invite a guest user to an app from the Access Panel


After an app is configured for self-service, application owners can use their own Access Panel to invite a guest
user to the app they want to share. The guest user doesn't necessarily need to be added to Azure AD in advance.
1. Open your Access Panel by going to https://myapps.microsoft.com .
2. Point to the app, select the ellipses (...), and then select Manage app.
3. At the top of the users list, select +.

4. In the Add members search box, type the email address for the guest user. Optionally, include a welcome
message.

5. Select Add to send an invitation to the guest user. After you send the invitation, the user account is
automatically added to the directory as a guest.

Invite someone to join a group that has access to the app


After an app is configured for self-service, application owners can invite guest users to the groups they manage
that have access to the apps they want to share. The guest users don't have to already exist in the directory. The
application owner follows these steps to invite a guest user to the group so that they can access the app.
1. Make sure you're an owner of the self-service group that has access to the app you want to share.
2. Open your Access Panel by going to https://myapps.microsoft.com .
3. Select the Groups app.

4. Under Groups I own, select the group that has access to the app you want to share.

5. At the top of the group members list, select +.

6. In the Add members search box, type the email address for the guest user. Optionally, include a welcome
message.

7. Select Add to automatically send the invitation to the guest user. After you send the invitation, the user
account is automatically added to the directory as a guest.

Prerequisites
Self-service app management requires some initial setup by a Global Administrator and an Azure AD
administrator. As part of this setup, you'll configure the app for self-service and assign a group to the app that the
application owner can manage. You can also configure the group to allow anyone to request membership but
require a group owner's approval. (Learn more about self-service group management.)

NOTE
You cannot add guest users to a dynamic group or to a group that is synced with on-premises Active Directory.

Enable self-service group management for your tenant


1. Sign in to the Azure portal as a Global Administrator.
2. In the navigation panel, select Azure Active Directory.
3. Select Groups.
4. Under Settings, select General.
5. Under Self Service Group Management, next to Owners can manage group membership requests in
the Access Panel, select Yes.
6. Select Save.
Create a group to assign to the app and make the user an owner
1. Sign in to the Azure portal as an Azure AD administrator or Global Administrator.
2. In the navigation panel, select Azure Active Directory.
3. Select Groups.
4. Select New group.
5. Under Group type, select Security.
6. Type a Group name and Group description.
7. Under Membership type, select Assigned.
8. Select Create, and close the Group page.
9. On the Groups - All groups page, open the group.
10. Under Manage, select Owners > Add owners. Search for the user who should manage access to the
application. Select the user, and then click Select.
Configure the app for self-service and assign the group to the app
1. Sign in to the Azure portal as an Azure AD administrator or Global Administrator.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Enterprise applications > All applications.
4. In the application list, find and open the app.
5. Under Manage, select Single sign-on, and configure the application for single sign-on. (For details, see
how to manage single sign-on for enterprise apps.)
6. Under Manage, select Self-service, and set up self-service app access. (For details, see how to use self-
service app access.)

NOTE
For the setting To which group should assigned users be added? select the group you created in the previous
section.

7. Under Manage, select Users and groups, and verify that the self-service group you created appears in the
list.
8. To add the app to the group owner's Access Panel, select Add user > Users and groups. Search for the
group owner and select the user, click Select, and then click Assign to add the user to the app.

Next steps
See the following articles on Azure AD B2B collaboration:
What is Azure AD B2B collaboration?
How do Azure Active Directory admins add B2B collaboration users?
B2B collaboration invitation redemption
Azure AD B2B collaboration licensing
Add Google as an identity provider for B2B guest
users (preview)
6/26/2019 • 4 minutes to read • Edit Online

Google federation is a public preview feature of Azure Active Directory. For more information about previews, see Supplemental
Terms of Use for Microsoft Azure Previews.

By setting up federation with Google, you can allow invited users to sign in to your shared apps and resources with
their own Google accounts, without having to create Microsoft Accounts (MSAs) or Azure AD accounts.

NOTE
Your Google guest users must sign in using a link that includes the tenant context (for example,
https://myapps.microsoft.com/?tenantid=<tenant id> or https://portal.azure.com/<tenant id> , or in the case of a
verified domain, https://myapps.microsoft.com/<verified domain>.onmicrosoft.com ). Direct links to applications and
resources also work as long as they include the tenant context. Guest users are currently unable to sign in using endpoints
that have no tenant context. For example, using https://myapps.microsoft.com , https://portal.azure.com , or the
Teams common endpoint will result in an error.

What is the experience for the Google user?


When you send an invitation to a Google Gmail user, the guest user should access your shared apps or resources
using a link that includes the tenant context. Their experience varies depending on whether they're already signed
in to Google:
If the guest user is not signed in to Google, they're prompted to sign in to Google.
If the guest user is already signed in to Google, they'll be prompted to choose the account they want to use.
They must choose the account you used to invite them.
If the guest user sees a "header too long" error, they can try clearing their cookies, or they can open a private or
incognito window and try signing in again.
Step 1: Configure a Google developer project
First, create a new project in the Google Developers Console to obtain a client ID and a client secret that you can
later add to Azure AD.
1. Go to the Google APIs at https://console.developers.google.com, and sign in with your Google account. We
recommend that you use a shared team Google account.
2. Create a new project: On the Dashboard, select Create Project, and then select Create. On the New Project
page, enter a Project Name, and then select Create.

3. Make sure your new project is selected in the project menu. Then open the menu in the upper left and select
APIs & Services > Credentials.

4. Choose the OAuth consent screen tab and enter an Application name. (Leave the other settings.)

5. Scroll to the Authorized domains section and enter microsoftonline.com.

6. Select Save.
7. Choose the Credentials tab. In the Create credentials menu, choose OAuth client ID.
8. Under Application type, choose Web application, and then under Authorized redirect URIs, enter the
following URIs:
https://login.microsoftonline.com

https://login.microsoftonline.com/te/<directory id>/oauth2/authresp
(where <directory id> is your directory ID )

NOTE
To find your directory ID, go to https://portal.azure.com, and under Azure Active Directory, choose
Properties and copy the Directory ID.
9. Select Create. Copy the client ID and client secret, which you'll use when you add the identity provider in
the Azure AD portal.

Step 2: Configure Google federation in Azure AD


Now you'll set the Google client ID and client secret, either by entering it in the Azure AD portal or by using
PowerShell. Be sure to test your Google federation configuration by inviting yourself using a Gmail address and
trying to redeem the invitation with your invited Google account.
To configure Google federation in the Azure AD portal
1. Go to the Azure portal. In the left pane, select Azure Active Directory.
2. Select Organizational Relationships.
3. Select Identity providers, and then click the Google button.
4. Enter a name. Then enter the client ID and client secret you obtained earlier. Select Save.

To configure Google federation by using PowerShell


1. Install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview ).
2. Run the following command: Connect-AzureAD .
3. At the sign-in prompt, sign in with the managed Global Administrator account.
4. Run the following command:
New-AzureADMSIdentityProvider -Type Google -Name Google -ClientId [Client ID] -ClientSecret [Client
secret]

NOTE
Use the client id and client secret from the app you created in "Step 1: Configure a Google developer project." For
more information, see the New-AzureADMSIdentityProvider article.

How do I remove Google federation?


You can delete your Google federation setup. If you do so, Google guest users who have already redeemed their
invitation will not be able to sign in, but you can give them access to your resources again by deleting them from
the directory and re-inviting them.
To delete Google federation in the Azure AD portal:
1. Go to the Azure portal. In the left pane, select Azure Active Directory.
2. Select Organizational Relationships.
3. Select Identity providers.
4. On the Google line, select the context menu (...) and then select Delete.

5. Select Yes to confirm deletion.


To delete Google federation by using PowerShell:
1. Install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview ).
2. Run Connect-AzureAD .
3. In the login in prompt, sign in with the managed Global Administrator account.
4. Enter the following command:
Remove-AzureADMSIdentityProvider -Id Google-OAUTH

NOTE
For more information, see Remove-AzureADMSIdentityProvider.
Email one-time passcode authentication (preview)
5/20/2019 • 6 minutes to read • Edit Online

Email one-time passcode is a public preview feature of Azure Active Directory. For more information about previews, see
Supplemental Terms of Use for Microsoft Azure Previews.

This article describes how to enable Email one-time passcode authentication for B2B guest users. The Email one-
time passcode feature authenticates B2B guest users when they can't be authenticated through other means like
Azure AD, a Microsoft account (MSA), or Google federation. With one-time passcode authentication, there's no
need to create a Microsoft account. When the guest user redeems an invitation or accesses a shared resource, they
can request a temporary code, which is sent to their email address. Then they enter this code to continue signing
in.
This feature is currently available for preview (see Opting in to the preview below ). After preview, this feature will
be turned on by default for all tenants.

NOTE
One-time passcode users must sign in using a link that includes the tenant context (for example,
https://myapps.microsoft.com/?tenantid=<tenant id> or https://portal.azure.com/<tenant id> , or in the case of a
verified domain, https://myapps.microsoft.com/<verified domain>.onmicrosoft.com ). Direct links to applications and
resources also work as long as they include the tenant context. Guest users are currently unable to sign in using endpoints
that have no tenant context. For example, using https://myapps.microsoft.com , https://portal.azure.com , or the
Teams common endpoint will result in an error.

User experience for one-time passcode guest users


With one-time passcode authentication, the guest user can redeem your invitation by clicking a direct link or by
using the invitation email. In either case, a message in the browser indicates that a code will be sent to the guest
user's email address. The guest user selects Send code:
A passcode is sent to the user’s email address. The user retrieves the passcode from the email and enters it in the
browser window:

The guest user is now authenticated, and they can see the shared resource or continue signing in.

NOTE
One-time passcodes are valid for 30 minutes. After 30 minutes, that specific one-time passcode is no longer valid, and the
user must request a new one. User sessions expire after 24 hours. After that time, the guest user receives a new passcode
when they access the resource. Session expiration provides added security, especially when a guest user leaves their company
or no longer needs access.
When does a guest user get a one-time passcode?
When a guest user redeems an invitation or uses a link to a resource that has been shared with them, they’ll
receive a one-time passcode if:
They do not have an Azure AD account
They do not have a Microsoft account
The inviting tenant did not set up Google federation for @gmail.com and @googlemail.com users
At the time of invitation, there's no indication that the user you're inviting will use one-time passcode
authentication. But when the guest user signs in, one-time passcode authentication will be the fallback method if
no other authentication methods can be used.
You can view guest users who authenticate with one-time passcodes in the Azure portal by going to Azure Active
Directory > Organizational relationships > Users from other organizations.

NOTE
When a user redeems a one-time passcode and later obtains an MSA, Azure AD account, or other federated account, they'll
continue to be authenticated using a one-time passcode. If you want to update their authentication method, you can delete
their guest user account and reinvite them.

Example
Guest user [email protected] is invited to Fabrikam, which does not have Google federation set up. Alex does
not have a Microsoft account. They'll receive a one-time passcode for authentication.

Opting in to the preview


It might take a few minutes for the opt-in action to take effect. After that, only newly invited users who meet the
conditions above will use one-time passcode authentication. Guest users who previously redeemed an invitation
will continue to use their same authentication method.
To opt in using the Azure AD portal
1. Sign in to the Azure portal as an Azure AD global administrator.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Organizational Relationships.
4. Select Settings.
5. Under Enable Email One-Time Passcode for guests (Preview), select Yes.
To opt in using PowerShell
First, you'll need to install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview ).
Then you'll determine whether B2B policies already exist and run the appropriate commands.
Prerequisite: Install the latest AzureADPreview module
First, check which modules you have installed. Open Windows PowerShell as an elevated user (Run as
administrator), and run the following command:

Get-Module -ListAvailable AzureAD*

If the AzureADPreview module displays with no message indicating there’s a later version, you’re set. Otherwise,
based on the output, do one of the following:
If no results are returned, run the following command to install the AzureADPreview module:

Install-Module AzureADPreview

If only the AzureAD module shows up in the results, run the following commands to install the
AzureADPreview module:

Uninstall-Module AzureAD
Install-Module AzureADPreview

If only the AzureADPreview module shows up in the results, but you receive a message that indicates
there's a later version, run the following commands to update the module:

Uninstall-Module AzureADPreview
Install-Module AzureADPreview

You might receive a prompt that you're installing the module from an untrusted repository. This occurs if you
haven't previously set the PSGallery repository as a trusted repository. Press Y to install the module.
Check for existing policies and opt in
Next, check to see if a B2BManagementPolicy currently exists by running the following:

$currentpolicy = Get-AzureADPolicy | ?{$_.Type -eq 'B2BManagementPolicy' -and $_.IsOrganizationDefault -eq


$true} | select -First 1
$currentpolicy -ne $null

If the output is False, the policy doesn't currently exist. Create a new B2BManagementPolicy and opt in to
the preview by running the following:

$policyValue=@("{`"B2BManagementPolicy`":{`"PreviewPolicy`":{`"Features`":[`"OneTimePasscode`"]}}}")
New-AzureADPolicy -Definition $policyValue -DisplayName B2BManagementPolicy -Type B2BManagementPolicy -
IsOrganizationDefault $true

If the output is True, the B2BManagementPolicy policy currently exists. To update the policy and opt in to
the preview, run the following:
$policy = $currentpolicy.Definition | ConvertFrom-Json
$features=[PSCustomObject]@{'Features'=@('OneTimePasscode')}; $policy.B2BManagementPolicy | Add-Member
'PreviewPolicy' $features -Force; $policy.B2BManagementPolicy
$updatedPolicy = $policy | ConvertTo-Json -Depth 3
Set-AzureADPolicy -Definition $updatedPolicy -Id $currentpolicy.Id

Opting out of the preview after opting in


It may take a few minutes for the opt-out action to take effect. If you turn off the preview, any guest users who
have redeemed a one-time passcode will not be able to sign in. You can delete the guest user and reinvite the user
to enable them to sign in again using another authentication method.
To turn off the preview using the Azure AD portal
1. Sign in to the Azure portal as an Azure AD global administrator.
2. In the navigation pane, select Azure Active Directory.
3. Under Manage, select Organizational Relationships.
4. Select Settings.
5. Under Enable Email One-Time Passcode for guests (Preview), select No.
To turn off the preview using PowerShell
Install the latest AzureADPreview module if you don’t have it already (see Prerequisite: Install the latest
AzureADPreview module above). Then, verify that the one-time passcode preview policy currently exists by
running the following:

$currentpolicy = Get-AzureADPolicy | ?{$_.Type -eq 'B2BManagementPolicy' -and $_.IsOrganizationDefault -eq


$true} | select -First 1
($currentPolicy -ne $null) -and ($currentPolicy.Definition -like "*OneTimePasscode*")

If the output is True, opt out of the preview by running the following:

$policy = $currentpolicy.Definition | ConvertFrom-Json


$policy.B2BManagementPolicy.PreviewPolicy.Features =
$policy.B2BManagementPolicy.PreviewPolicy.Features.Where({$_ -ne "OneTimePasscode"})
$updatedPolicy = $policy | ConvertTo-Json -Depth 3
Set-AzureADPolicy -Definition $updatedPolicy -Id $currentpolicy.Id
Direct federation with AD FS and third-party providers
for guest users (preview)
8/7/2019 • 10 minutes to read • Edit Online

Direct federation is a public preview feature of Azure Active Directory. For more information about previews, see Supplemental Terms of
Use for Microsoft Azure Previews.

This article describes how to set up direct federation with another organization for B2B collaboration. You can set up
direct federation with any organization whose identity provider (IdP ) supports the SAML 2.0 or WS-Fed protocol. When
you set up direct federation with a partner's IdP, new guest users from that domain can use their own IdP-managed
organizational account to sign in to your Azure AD tenant and start collaborating with you. There's no need for the
guest user to create a separate Azure AD account.

NOTE
Direct federation guest users must sign in using a link that includes the tenant context (for example,
https://myapps.microsoft.com/?tenantid=<tenant id> or https://portal.azure.com/<tenant id> , or in the case of a
verified domain, https://myapps.microsoft.com/\<verified domain>.onmicrosoft.com ). Direct links to applications and
resources also work as long as they include the tenant context. Direct federation users are currently unable to sign in using
common endpoints that have no tenant context. For example, using https://myapps.microsoft.com ,
https://portal.azure.com , or https://teams.microsoft.com will result in an error.

When is a guest user authenticated with direct federation?


After you set up direct federation with an organization, any new guest users you invite will be authenticated using direct
federation. It’s important to note that setting up direct federation doesn’t change the authentication method for guest
users who have already redeemed an invitation from you. Here are some examples:
If guest users have already redeemed invitations from you, and you subsequently set up direct federation with their
organization, those guest users will continue to use the same authentication method they used before you set up
direct federation.
If you set up direct federation with a partner organization and invite guest users, and then the partner organization
later moves to Azure AD, the guest users who have already redeemed invitations will continue to use direct
federation, as long as the direct federation policy in your tenant exists.
If you delete direct federation with a partner organization, any guest users currently using direct federation will be
unable to sign in.
In any of these scenarios, you can update a guest user’s authentication method by deleting the guest user account from
your directory and reinviting them.
Direct federation is tied to domain namespaces, such as contoso.com and fabrikam.com. When establishing a direct
federation configuration with AD FS or a third-party IdP, organizations associate one or more domain namespaces to
these IdPs.

End-user experience
With direct federation, guest users sign into your Azure AD tenant using their own organizational account. When they
are accessing shared resources and are prompted for sign-in, direct federation users are redirected to their IdP. After
successful sign-in, they are returned to Azure AD to access resources. Direct federation users’ refresh tokens are valid
for 12 hours, the default length for passthrough refresh token in Azure AD. If the federated IdP has SSO enabled, the
user will experience SSO and will not see any sign-in prompt after initial authentication.

Limitations
DNS-verified domains in Azure AD
The domain you want to federate with must not be DNS-verified in Azure AD. You're allowed to set up direct federation
with unmanaged (email-verified or "viral") Azure AD tenants because they aren't DNS-verified.
Authentication URL
Direct federation is only allowed for policies where the authentication URL’s domain matches the target domain, or
where the authentication URL is one of these allowed identity providers (this list is subject to change):
accounts.google.com
pingidentity.com
login.pingone.com
okta.com
my.salesforce.com
federation.exostar.com
federation.exostartest.com
For example, when setting up direct federation for fabrikam.com, the authentication URL https://fabrikam.com/adfs
will pass the validation. A host in the same domain will also pass, for example https://sts.fabrikam.com/adfs . However,
the authentication URL https://fabrikamconglomerate.com/adfs or https://fabrikam.com.uk/adfs for the same domain
won't pass.
Signing certificate renewal
If you specify the metadata URL in the identity provider settings, Azure AD will automatically renew the signing
certificate when it expires. However, if the certificate is rotated for any reason before the expiration time, or if you don't
provide a metadata URL, Azure AD will be unable to renew it. In this case, you'll need to update the signing certificate
manually.
Limit on federation relationships
Currently, a maximum of 1,000 federation relationships is supported. This limit includes both internal federations and
direct federations.

Frequently asked questions


Can I set up direct federation with a domain for which an unmanaged (email-verified) tenant exists?
Yes. If the domain hasn't been verified and the tenant hasn't undergone an admin takeover, you can set up direct
federation with that domain. Unmanaged, or email-verified, tenants are created when a user redeems a B2B invitation or
performs a self-service sign-up for Azure AD using a domain that doesn’t currently exist. You can set up direct
federation with these domains. If you try to set up direct federation with a DNS-verified domain, either in the Azure
portal or via PowerShell, you'll see an error.
If direct federation and email one-time passcode authentication are both enabled, which method takes precedence?
When direct federation is established with a partner organization, it takes precedence over email one-time passcode
authentication for new guest users from that organization. If a guest user redeemed an invitation using one-time
passcode authentication before you set up direct federation, they'll continue to use one-time passcode authentication.
Does direct federation address sign-in issues due to a partially synced tenancy?
No, the email one-time passcode feature should be used in this scenario. A “partially synced tenancy” refers to a partner
Azure AD tenant where on-premises user identities aren't fully synced to the cloud. A guest whose identity doesn’t yet
exist in the cloud but who tries to redeem your B2B invitation won’t be able to sign in. The one-time passcode feature
would allow this guest to sign in. The direct federation feature addresses scenarios where the guest has their own IdP-
managed organizational account, but the organization has no Azure AD presence at all.

Step 1: Configure the partner organization’s identity provider


First, your partner organization needs to configure their identity provider with the required claims and relying party
trusts.

NOTE
To illustrate how to configure an identity provider for direct federation, we’ll use Active Directory Federation Services (AD FS) as an
example. See the article Configure direct federation with AD FS, which gives examples of how to configure AD FS as a SAML 2.0 or
WS-Fed identity provider in preparation for direct federation.

SAML 2.0 configuration


Azure AD B2B can be configured to federate with identity providers that use the SAML protocol with specific
requirements listed below. For more information about setting up a trust between your SAML identity provider and
Azure AD, see Use a SAML 2.0 Identity Provider (IdP ) for Single Sign-On.

NOTE
NOTE The target domain for direct federation must not be DNS-verified on Azure AD. The authentication URL domain must match
the target domain or it must be the domain of an allowed identity provider. See the Limitations section for details.

Required SAML 2.0 attributes and claims


The following tables show requirements for specific attributes and claims that must be configured at the third-party
identity provider. To set up direct federation, the following attributes must be received in the SAML 2.0 response from
the identity provider. These attributes can be configured by linking to the online security token service XML file or by
entering them manually.
Required attributes for the SAML 2.0 response from the IdP:

ATTRIBUTE VALUE

AssertionConsumerService https://login.microsoftonline.com/login.srf

Audience urn:federation:MicrosoftOnline

Issuer The issuer URI of the partner IdP, for example


http://www.example.com/exk10l6w90DHM0yi...

Required claims for the SAML 2.0 token issued by the IdP:

ATTRIBUTE VALUE

NameID Format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

WS-Fed configuration
Azure AD B2B can be configured to federate with identity providers that use the WS-Fed protocol with some specific
requirements as listed below. Currently, the two WS-Fed providers have been tested for compatibility with Azure AD
include AD FS and Shibboleth. For more information about establishing a relying party trust between a WS-Fed
compliant provider with Azure AD, see the "STS Integration Paper using WS Protocols" available in the Azure AD
Identity Provider Compatibility Docs.
NOTE
The target domain for direct federation must not be DNS-verified on Azure AD. The authentication URL domain must match either
the target domain or the domain of an allowed identity provider. See the Limitations section for details.

Required WS-Fed attributes and claims


The following tables show requirements for specific attributes and claims that must be configured at the third-party
WS-Fed identity provider. To set up direct federation, the following attributes must be received in the WS-Fed message
from the identity provider. These attributes can be configured by linking to the online security token service XML file or
by entering them manually.
Required attributes in the WS-Fed message from the IdP:

ATTRIBUTE VALUE

PassiveRequestorEndpoint https://login.microsoftonline.com/login.srf

Audience urn:federation:MicrosoftOnline

Issuer The issuer URI of the partner IdP, for example


http://www.example.com/exk10l6w90DHM0yi...

Required claims for the WS-Fed token issued by the IdP:

ATTRIBUTE VALUE

ImmutableID http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID

emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Step 2: Configure direct federation in Azure AD


Next, you'll configure federation with the identity provider configured in step 1 in Azure AD. You can use either the
Azure AD portal or PowerShell. It might take 5-10 minutes before the direct federation policy takes effect. During this
time, don't attempt to redeem an invitation for the direct federation domain. The following attributes are required:
Issuer URI of partner IdP
Passive authentication endpoint of partner IdP (only https is supported)
Certificate
To configure direct federation in the Azure AD portal
1. Go to the Azure portal. In the left pane, select Azure Active Directory.
2. Select Organizational Relationships.
3. Select Identity providers, and then select New SAML/WS-Fed IdP.
4. On the New SAML/WS-Fed IdP page, under Identity provider protocol, select SAML or WS-FED.

5. Enter your partner organization’s domain name, which will be the target domain name for direct federation
6. You can upload a metadata file to populate metadata details. If you choose to input metadata manually, enter the
following information:
Domain name of partner IdP
Entity ID of partner IdP
Passive requestor endpoint of partner IdP
Certificate
NOTE
Metadata URL is optional, however we strongly recommend it. If you provide the metadata URL, Azure AD can
automatically renew the signing certificate when it expires. If the certificate is rotated for any reason before the expiration
time or if you do not provide a metadata URL, Azure AD will be unable to renew it. In this case, you'll need to update the
signing certificate manually.

7. Select Save.
To configure direct federation in Azure AD using PowerShell
1. Install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview ). (If you need detailed
steps, the quickstart for adding a guest user includes the section Install the latest AzureADPreview module.)
2. Run the following command:

Connect-AzureAD

3. At the sign-in prompt, sign in with the managed Global Administrator account.
4. Run the following commands, replacing the values from the federation metadata file. For AD FS Server and Okta,
the federation file is federationmetadata.xml, for example:
https://sts.totheclouddemo.com/federationmetadata/2007-06/federationmetadata.xml .

$federationSettings = New-Object Microsoft.Open.AzureAD.Model.DomainFederationSettings


$federationSettings.PassiveLogOnUri ="https://sts.totheclouddemo.com/adfs/ls/"
$federationSettings.LogOffUri = $federationSettings.PassiveLogOnUri
$federationSettings.IssuerUri = "http://sts.totheclouddemo.com/adfs/services/trust"
$federationSettings.MetadataExchangeUri="https://sts.totheclouddemo.com/adfs/services/trust/mex"
$federationSettings.SigningCertificate= <Replace with X509 signing cert’s public key>
$federationSettings.PreferredAuthenticationProtocol="WsFed" OR "Samlp"
$domainName = <Replace with domain name>
New-AzureADExternalDomainFederation -ExternalDomainName $domainName -FederationSettings $federationSettings

Step 3: Test direct federation in Azure AD


Now test your direct federation setup by inviting a new B2B guest user. For details, see Add Azure AD B2B collaboration
users in the Azure portal.

How do I edit a direct federation relationship?


1. Go to the Azure portal. In the left pane, select Azure Active Directory.
2. Select Organizational Relationships.
3. Select Identity providers
4. Under SAML/WS-Fed identity providers, select the provider.
5. In the identity provider details pane, update the values.
6. Select Save.

How do I remove direct federation?


You can remove your direct federation setup. If you do, direct federation guest users who have already redeemed their
invitations won't be able to sign in. But you can give them access to your resources again by deleting them from the
directory and reinviting them. To remove direct federation with an identity provider in the Azure AD portal:
1. Go to the Azure portal. In the left pane, select Azure Active Directory.
2. Select Organizational Relationships.
3. Select Identity providers.
4. Select the identity provider, and then select Delete.
5. Select Yes to confirm deletion.
To remove direct federation with an identity provider by using PowerShell:
1. Install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview ).
2. Run the following command:

Connect-AzureAD

3. At the sign-in prompt, sign in with the managed Global Administrator account.
4. Enter the following command:

Remove-AzureADExternalDomainFederation -ExternalDomainName $domainName


Example: Direct federation with Active Directory
Federation Services (AD FS) (preview)
7/3/2019 • 6 minutes to read • Edit Online

Direct federation is a public preview feature of Azure Active Directory. For more information about previews, see Supplemental Terms of
Use for Microsoft Azure Previews.

This article describes how to set up direct federation using Active Directory Federation Services (AD FS ) as either a
SAML 2.0 or WS-Fed identity provider. To support direct federation, certain attributes and claims must be configured at
the identity provider. To illustrate how to configure an identity provider for direct federation, we’ll use Active Directory
Federation Services (AD FS ) as an example. We’ll show how to set up AD FS both as a SAML identity provider and as a
WS-Fed identity provider.

NOTE
This article describes how to set up AD FS for both SAML and WS-Fed for illustration purposes. For direct federation integrations
where the identity provider is AD FS, we recommend using WS-Fed as the protocol.

Configure AD FS for SAML 2.0 direct federation


Azure AD B2B can be configured to federate with identity providers that use the SAML protocol with specific
requirements listed below. To illustrate the SAML configuration steps, this section shows how to set up AD FS for SAML
2.0.
To set up direct federation, the following attributes must be received in the SAML 2.0 response from the identity
provider. These attributes can be configured by linking to the online security token service XML file or by entering them
manually. Step 12 in Create a test AD FS instance describes how to find the AD FS endpoints or how to generate your
metadata URL, for example https://fs.iga.azure-test.net/federationmetadata/2007-06/federationmetadata.xml .

ATTRIBUTE VALUE

AssertionConsumerService https://login.microsoftonline.com/login.srf

Audience urn:federation:MicrosoftOnline

Issuer The issuer URI of the partner IdP, for example


http://www.example.com/exk10l6w90DHM0yi...

The following claims need to be configured in the SAML 2.0 token issued by the identity provider:

ATTRIBUTE VALUE

NameID Format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

The next section illustrates how to configure the required attributes and claims using AD FS as an example of a SAML
2.0 identity provider.
Before you begin
An AD FS server must already be set up and functioning before you begin this procedure. For help with setting up an
AD FS server, see Create a test AD FS 3.0 instance on an Azure virtual machine.
Add the claim description
1. On your AD FS server, select Tools > AD FS management.
2. In the navigation pane, select Service > Claim Descriptions.
3. Under Actions, select Add Claim Description.
4. In the Add a Claim Description window, specify the following values:
Display Name: Persistent Identifier
Claim identifier: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
Select the check box for Publish this claim description in federation metadata as a claim type that this
federation service can accept.
Select the check box for Publish this claim description in federation metadata as a claim type that this
federation service can send.
5. Click Ok.
Add the relying party trust and claim rules
1. On the AD FS server, go to Tools > AD FS management.
2. In the navigation pane, select Trust Relationships > Relying Party Trusts.
3. Under Actions, select Add Relying Party Trust.
4. In the add relying party trust wizard for Select Data Source, use the option Import data about the relying
party published online or on a local network. Specify this federation metadata URL-
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Leave other default
selections. Select Close.
5. The Edit Claim Rules wizard opens.
6. In the Edit Claim Rules wizard, select Add Rule. In Choose Rule Type, select Send LDAP Attributes as
Claims. Select Next.
7. In Configure Claim Rule, specify the following values:
Claim rule name: Email claim rule
Attribute store: Active Directory
LDAP Attribute: E-Mail-Addresses
Outgoing Claim Type: E-Mail Address
8. Select Finish.
9. The Edit Claim Rules window will show the new rule. Click Apply.
10. Click Ok.
Create an email transform rule
1. Go to Edit Claim Rules and click Add Rule. In Choose Rule Type, select Transform an Incoming Claim and
click Next.
2. In Configure Claim Rule, specify the following values:
Claim rule name: Email transform rule
Incoming claim type: E-mail Address
Outgoing claim type: Name ID
Outgoing name ID format: Persistent Identifier
Select Pass through all claim values.
3. Click Finish.
4. The Edit Claim Rules window will show the new rules. Click Apply.
5. Click OK. The AD FS server is now configured for direct federation using the SAML 2.0 protocol.

Configure AD FS for WS-Fed direct federation


Azure AD B2B can be configured to federate with identity providers that use the WS-Fed protocol with the specific
requirements listed below. Currently, the two WS-Fed providers have been tested for compatibility with Azure AD
include AD FS and Shibboleth. Here, we’ll use Active Directory Federation Services (AD FS ) as an example of the WS-
Fed identity provider. For more information about establishing a relying party trust between a WS-Fed compliant
provider with Azure AD, download the Azure AD Identity Provider Compatibility Docs.
To set up direct federation, the following attributes must be received in the WS-Fed message from the identity provider.
These attributes can be configured by linking to the online security token service XML file or by entering them manually.
Step 12 in Create a test AD FS instance describes how to find the AD FS endpoints or how to generate your metadata
URL, for example https://fs.iga.azure-test.net/federationmetadata/2007-06/federationmetadata.xml .

ATTRIBUTE VALUE

PassiveRequestorEndpoint https://login.microsoftonline.com/login.srf

Audience urn:federation:MicrosoftOnline

Issuer The issuer URI of the partner IdP, for example


http://www.example.com/exk10l6w90DHM0yi...

Required claims for the WS-Fed token issued by the IdP:

ATTRIBUTE VALUE

ImmutableID http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID

emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

The next section illustrates how to configure the required attributes and claims using AD FS as an example of a WS-Fed
identity provider.
Before you begin
An AD FS server must already be set up and functioning before you begin this procedure. For help with setting up an
AD FS server, see Create a test AD FS 3.0 instance on an Azure virtual machine.
Add the relying party trust and claim rules
1. On the AD FS server, go to Tools > AD FS management.
2. In the navigation pane, select Trust Relationships > Relying Party Trusts.
3. Under Actions, select Add Relying Party Trust.
4. In the add relying party trust wizard, for Select Data Source, use the option Import data about the relying
party published online or on a local network. Specify this federation metadata URL:
https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml . Leave other default
selections. Select Close.
5. The Edit Claim Rules wizard opens.
6. In the Edit Claim Rules wizard, select Add Rule. In Choose Rule Type, select Send Claims Using a Custom
Rule. Select Next.
7. In Configure Claim Rule, specify the following values:
Claim rule name: Issue Immutable Id
Custom rule:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(store =
"Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query =
"samAccountName={0};objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)",
"${user}"), param = c.Value);
8. Select Finish.
9. The Edit Claim Rules window will show the new rule. Click Apply.
10. In the same Edit Claim Rules wizard, select Add Rule. In Cohose Rule Type, select Send LDAP Attributes as
Claims. Select Next.
11. In Configure Claim Rule, specify the following values:
Claim rule name: Email claim rule
Attribute store: Active Directory
LDAP Attribute: E-Mail-Addresses
Outgoing Claim Type: E-Mail Address
12. Select Finish.
13. The Edit Claim Rules window will show the new rule. Click Apply.
14. Click OK. The AD FS server is now configured for direct federation using WS-Fed.

Next steps
Next, you'll configure direct federation in Azure AD either in the Azure AD portal or by using PowerShell.
Allow or block invitations to B2B users from specific
organizations
7/16/2019 • 5 minutes to read • Edit Online

You can use an allow list or a deny list to allow or block invitations to B2B users from specific organizations. For
example, if you want to block personal email address domains, you can set up a deny list that contains domains like
Gmail.com and Outlook.com. Or, if your business has a partnership with other businesses like Contoso.com,
Fabrikam.com, and Litware.com, and you want to restrict invitations to only these organizations, you can add
Contoso.com, Fabrikam.com, and Litware.com to your allow list.

Important considerations
You can create either an allow list or a deny list. You can't set up both types of lists. By default, whatever
domains are not in the allow list are on the deny list, and vice versa.
You can create only one policy per organization. You can update the policy to include more domains, or you can
delete the policy to create a new one.
The number of domains you can add to an allow list or deny list is limited only by the size of the policy. The
maximum size of the entire policy is 25 KB (25,000 characters), which includes the allow list or deny list and any
other parameters configured for other features.
This list works independently from OneDrive for Business and SharePoint Online allow/block lists. If you want
to restrict individual file sharing in SharePoint Online, you need to set up an allow or deny list for OneDrive for
Business and SharePoint Online. For more information, see Restricted domains sharing in SharePoint Online
and OneDrive for Business.
The list does not apply to external users who have already redeemed the invitation. The list will be enforced
after the list is set up. If a user invitation is in a pending state, and you set a policy that blocks their domain, the
user's attempt to redeem the invitation will fail.

Set the allow or deny list policy in the portal


By default, the Allow invitations to be sent to any domain (most inclusive) setting is enabled. In this case,
you can invite B2B users from any organization.
Add a deny list
This is the most typical scenario, where your organization wants to work with almost any organization, but wants
to prevent users from specific domains to be invited as B2B users.
To add a deny list:
1. Sign in to the Azure portal.
2. Select Azure Active Directory > Users > User settings.
3. Under External users, select Manage external collaboration settings.
4. Under Collaboration restrictions, select Deny invitations to the specified domains.
5. Under TARGET DOMAINS, enter the name of one of the domains that you want to block. For multiple
domains, enter each domain on a new line. For example:
6. When you're done, click Save.
After you set the policy, if you try to invite a user from a blocked domain, you receive a message saying that the
domain of the user is currently blocked by your invitation policy.
Add an allow list
This is a more restrictive configuration, where you can set specific domains in the allow list and restrict invitations
to any other organizations or domains that aren't mentioned.
If you want to use an allow list, make sure that you spend time to fully evaluate what your business needs are. If
you make this policy too restrictive, your users may choose to send documents over email, or find other non-IT
sanctioned ways of collaborating.
To add an allow list:
1. Sign in to the Azure portal.
2. Select Azure Active Directory > Users > User settings.
3. Under External users, select Manage external collaboration settings.
4. Under Collaboration restrictions, select Allow invitations only to the specified domains (most
restrictive).
5. Under TARGET DOMAINS, enter the name of one of the domains that you want to allow. For multiple
domains, enter each domain on a new line. For example:

6. When you're done, click Save.


After you set the policy, if you try to invite a user from a domain that's not on the allow list, you receive a message
saying that the domain of the user is currently blocked by your invitation policy.
Switch from allow to deny list and vice versa
If you switch from one policy to the other, this discards the existing policy configuration. Make sure to back up
details of your configuration before you perform the switch.

Set the allow or deny list policy using PowerShell


Prerequisite
To set the allow or deny list by using PowerShell, you must install the preview version of the Azure Active
Directory Module for Windows PowerShell. Specifically, install the AzureADPreviewmodule version2.0.0.98or
later.
To check the version of the module (and see if it's installed):
1. Open Windows PowerShell as an elevated user (Run as Administrator).
2. Run the following command to see if you have any versions of the Azure Active Directory Module for
Windows PowerShell installed on your computer:

Get-Module -ListAvailable AzureAD*

If the module is not installed, or you don't have a required version, do one of the following:
If no results are returned, run the following command to install the latest version of
theAzureADPreviewmodule:

Install-Module AzureADPreview

IfonlytheAzureADmodule is shown in the results, run the following commands to install


theAzureADPreviewmodule:

Uninstall-Module AzureAD
Install-Module AzureADPreview

IfonlytheAzureADPreviewmodule is shown in the results, but the version is less than2.0.0.98, run the
following commands to update it:

Uninstall-Module AzureADPreview
Install-Module AzureADPreview

If both theAzureADandAzureADPreviewmodules are shown in the results, but the version of


theAzureADPreviewmodule is less than2.0.0.98, run the following commands to update it:

Uninstall-Module AzureAD
Uninstall-Module AzureADPreview
Install-Module AzureADPreview

Use the AzureADPolicy cmdlets to configure the policy


To create an allow or deny list, use the New -AzureADPolicy cmdlet. The following example shows how to set a
deny list that blocks the "live.com" domain.
$policyValue = @("{`"B2BManagementPolicy`":{`"InvitationsAllowedAndBlockedDomainsPolicy`":{`"AllowedDomains`":
[],`"BlockedDomains`": [`"live.com`"]}}}")

New-AzureADPolicy -Definition $policyValue -DisplayName B2BManagementPolicy -Type B2BManagementPolicy -


IsOrganizationDefault $true

The following shows the same example, but with the policy definition inline.

New-AzureADPolicy -Definition @("{`"B2BManagementPolicy`":{`"InvitationsAllowedAndBlockedDomainsPolicy`":


{`"AllowedDomains`": [],`"BlockedDomains`": [`"live.com`"]}}}") -DisplayName B2BManagementPolicy -Type
B2BManagementPolicy -IsOrganizationDefault $true

To set the allow or deny list policy, use the Set-AzureADPolicy cmdlet. For example:

Set-AzureADPolicy -Definition $policyValue -Id $currentpolicy.Id

To get the policy, use the Get-AzureADPolicy cmdlet. For example:

$currentpolicy = Get-AzureADPolicy | ?{$_.Type -eq 'B2BManagementPolicy'} | select -First 1

To remove the policy, use the Remove-AzureADPolicy cmdlet. For example:

Remove-AzureADPolicy -Id $currentpolicy.Id

Next steps
For an overview of Azure AD B2B, see What is Azure AD B2B collaboration?
For information about Conditional Access and B2B collaboration, see Conditional Access for B2B collaboration
users.
Add B2B collaboration guest users without an
invitation link or email
6/12/2019 • 2 minutes to read • Edit Online

You can now invite guest users by sending out a direct link to a shared app. With this method, guest users no
longer need to use the invitation email, except in some special cases. A guest user clicks the app link, reviews and
accepts the privacy terms, and then seamlessly accesses the app. For more information, see B2B collaboration
invitation redemption.
Before this new method was available, you could invite guest users without requiring the invitation email by
adding an inviter (from your organization or from a partner organization) to the Guest inviter directory role, and
then having the inviter add guest users to the directory, groups, or applications through the UI or through
PowerShell. (If using PowerShell, you can suppress the invitation email altogether). For example:
1. A user in the host organization (for example, WoodGrove) invites one user from the partner organization (for
example, [email protected]) as Guest.
2. The administrator in the host organization sets up policies that allow Sam to identify and add other users from
the partner organization (Litware). (Sam must be added to the Guest inviter role.)
3. Now, Sam can add other users from Litware to the WoodGrove directory, groups, or applications without
needing invitations to be redeemed. If Sam has the appropriate enumeration privileges in Litware, it happens
automatically.
This original method still works. However, there's a small difference in behavior. If you use PowerShell, you'll
notice that an invited guest account now has a PendingAcceptance status instead of immediately showing
Accepted. Although the status is pending, the guest user can still sign in and access the app without clicking an
email invitation link. The pending status means that the user has not yet gone through the consent experience,
where they accept the privacy terms of the inviting organization. The guest user sees this consent screen when
they sign in for the first time.
If you invite a user to the directory, the guest user must access the resource tenant-specific Azure portal URL
directly (such as https://portal.azure.com/*resourcetenant*.onmicrosoft.com) to view and agree to the privacy
terms.

Next steps
What is Azure AD B2B collaboration?
B2B collaboration invitation redemption
Delegate invitations for Azure Active Directory B2B collaboration
How do information workers add B2B collaboration users?
Azure Active Directory B2B collaboration API and
customization
5/16/2019 • 2 minutes to read • Edit Online

We've had many customers tell us that they want to customize the invitation process in a way that works best for
their organizations. With our API, you can do just that. https://developer.microsoft.com/graph/docs/api-
reference/v1.0/resources/invitation

Capabilities of the invitation API


The API offers the following capabilities:
1. Invite an external user with any email address.

"invitedUserDisplayName": "Sam"
"invitedUserEmailAddress": "[email protected]"

2. Customize where you want your users to land after they accept their invitation.

"inviteRedirectUrl": "https://myapps.microsoft.com/"

3. Choose to send the standard invitation mail through us

"sendInvitationMessage": true

with a message to the recipient that you can customize

"customizedMessageBody": "Hello Sam, let's collaborate!"

4. And choose to cc: people you want to keep in the loop about your inviting this collaborator.
5. Or completely customize your invitation and onboarding workflow by choosing not to send notifications
through Azure AD.

"sendInvitationMessage": false

In this case, you get back a redemption URL from the API that you can embed in an email template, IM, or
other distribution method of your choice.
6. Finally, if you are an admin, you can choose to invite the user as member.

"invitedUserType": "Member"

Authorization model
The API can be run in the following authorization modes:
App + User mode
In this mode, whoever is using the API needs to have the permissions to be create B2B invitations.
App only mode
In app only context, the app needs the User.Invite.All scope for the invitation to succeed.
For more information, refer to: https://developer.microsoft.com/graph/docs/authorization/permission_scopes

PowerShell
You can use PowerShell to add and invite external users to an organization easily. Create an invitation using the
cmdlet:

New-AzureADMSInvitation

You can use the following options:


-InvitedUserDisplayName
-InvitedUserEmailAddress
-SendInvitationMessage
-InvitedUserMessageInfo
Invitation status
After you send an external user an invitation, you can use the Get-AzureADUser cmdlet to see if they've accepted
it. The following properties of Get-AzureADUser are populated when an external user is sent an invitation:
UserState indicates whether the invitation is PendingAcceptance or Accepted.
UserStateChangedOn shows the timestamp for the latest change to the UserState property.
You can use the Filter option to filter the results by UserState. The example below shows how to filter results to
show only users who have a pending invitation. The example also shows the Format-List option, which lets you
specify the properties to display.

Get-AzureADUser -Filter "UserState eq 'PendingAcceptance'" | Format-List -Property


DisplayName,UserPrincipalName,UserState,UserStateChangedOn

NOTE
Make sure you have the latest version of the AzureAD PowerShell module or AzureADPreview PowerShell module.

See also
Check out the invitation API reference in https://developer.microsoft.com/graph/docs/api-
reference/v1.0/resources/invitation.

Next steps
What is Azure AD B2B collaboration?
The elements of the B2B collaboration invitation email
B2B collaboration invitation redemption
Add B2B collaboration users without an invitation
Grant permissions to users from partner
organizations in your Azure Active Directory tenant
5/16/2019 • 2 minutes to read • Edit Online

Azure Active Directory (Azure AD ) B2B collaboration users are added as guest users to the directory, and guest
permissions in the directory are restricted by default. Your business may need some guest users to fill higher-
privilege roles in your organization. To support defining higher-privilege roles, guest users can be added to any
roles you desire, based on your organization's needs.

Default role

Global Administrator Role


Limited Administrator Role
Next steps
What is Azure AD B2B collaboration?
B2B collaboration user properties
Dynamic groups and Azure Active Directory B2B
collaboration
6/13/2019 • 2 minutes to read • Edit Online

What are dynamic groups?


Dynamic configuration of security group membership for Azure Active Directory (Azure AD ) is available in the
Azure portal. Administrators can set rules to populate groups that are created in Azure AD based on user
attributes (such as userType, department, or country/region). Members can be automatically added to or removed
from a security group based on their attributes. These groups can provide access to applications or cloud
resources (SharePoint sites, documents) and to assign licenses to members. Read more about dynamic groups in
Dedicated groups in Azure Active Directory.
The appropriate Azure AD Premium P1 or P2 licensing is required to create and use dynamic groups. Learn more
in the article Create attribute-based rules for dynamic group membership in Azure Active Directory.

What are the built-in dynamic groups?


The All users dynamic group enables tenant admins to create a group containing all users in the tenant with a
single click. By default, the All users group includes all users in the directory, including Members and Guests.
Within the new Azure Active Directory admin portal, you can choose to enable the All users group in the Group
Settings view.

Hardening the All users dynamic group


By default, the All users group contains your B2B collaboration (guest) users as well. You can further secure your
All users group by using a rule to remove guest users. The following illustration shows the All users group
modified to exclude guests.
You might also find it useful to create a new dynamic group that contains only guest users, so that you can apply
policies (such as Azure AD Conditional Access policies) to them. What such a group might look like:

Next steps
B2B collaboration user properties
Adding a B2B collaboration user to a role
Conditional Access for B2B collaboration users
Properties of an Azure Active Directory B2B
collaboration user
5/16/2019 • 5 minutes to read • Edit Online

This article describes the properties and states of the B2B guest user object in Azure Active Directory (Azure AD )
before and after invitation redemption. An Azure AD business-to-business (B2B ) collaboration user is a user with
UserType = Guest. This guest user typically is from a partner organization and has limited privileges in the
inviting directory, by default.
Depending on the inviting organization's needs, an Azure AD B2B collaboration user can be in one of the
following account states:
State 1: Homed in an external instance of Azure AD and represented as a guest user in the inviting
organization. In this case, the B2B user signs in by using an Azure AD account that belongs to the invited
tenant. If the partner organization doesn't use Azure AD, the guest user in Azure AD is still created. The
requirements are that they redeem their invitation and Azure AD verifies their email address. This
arrangement is also called a just-in-time (JIT) tenancy or a "viral" tenancy.
State 2: Homed in a Microsoft or other account and represented as a guest user in the host organization.
In this case, the guest user signs in with a Microsoft account or a social account (google.com or similar).
The invited user's identity is created as a Microsoft account in the inviting organization’s directory during
offer redemption.
State 3: Homed in the host organization's on-premises Active Directory and synced with the host
organization's Azure AD. You can use Azure AD Connect to sync the partner accounts to the cloud as
Azure AD B2B users with UserType = Guest. See Grant locally-managed partner accounts access to cloud
resources.
State 4: Homed in the host organization's Azure AD with UserType = Guest and credentials that the host
organization manages.

Now, let's see what an Azure AD B2B collaboration user looks like in Azure AD.
Before invitation redemption
State 1 and State 2 accounts are the result of inviting guest users to collaborate by using the guest users' own
credentials. When the invitation is initially sent to the guest user, an account is created in your directory. This
account doesn’t have any credentials associated with it because authentication is performed by the guest user's
identity provider. The Source property for the guest user account in your directory is set to Invited user.

After invitation redemption


After the guest user accepts the invitation, the Source property is updated based on the guest user’s identity
provider.
For guest users in State 1, the Source is External Azure Active Directory.
For guest users in State 2, the Source is Microsoft Account.

For guest users in State 3 and State 4, the Source property is set to Azure Active Directory or Windows
Server Active Directory, as described in the next section.
Key properties of the Azure AD B2B collaboration user
UserType
This property indicates the relationship of the user to the host tenancy. This property can have two values:
Member: This value indicates an employee of the host organization and a user in the organization's
payroll. For example, this user expects to have access to internal-only sites. This user is not considered an
external collaborator.
Guest: This value indicates a user who isn't considered internal to the company, such as an external
collaborator, partner, or customer. Such a user isn't expected to receive a CEO's internal memo or receive
company benefits, for example.

NOTE
The UserType has no relation to how the user signs in, the directory role of the user, and so on. This property
simply indicates the user's relationship to the host organization and allows the organization to enforce policies that
depend on this property.

Source
This property indicates how the user signs in.
Invited User: This user has been invited but has not yet redeemed an invitation.
External Active Directory: This user is homed in an external organization and authenticates by using an
Azure AD account that belongs to the other organization. This type of sign-in corresponds to State 1.
Microsoft account: This user is homed in a Microsoft account and authenticates by using a Microsoft
account. This type of sign-in corresponds to State 2.
Windows Server Active Directory: This user is signed in from on-premises Active Directory that belongs
to this organization. This type of sign-in corresponds to State 3.
Azure Active Directory: This user authenticates by using an Azure AD account that belongs to this
organization. This type of sign-in corresponds to State 4.

NOTE
Source and UserType are independent properties. A value of Source does not imply a particular value for UserType.

Can Azure AD B2B users be added as members instead of guests?


Typically, an Azure AD B2B user and guest user are synonymous. Therefore, an Azure AD B2B collaboration user
is added as a user with UserType = Guest by default. However, in some cases, the partner organization is a
member of a larger organization to which the host organization also belongs. If so, the host organization might
want to treat users in the partner organization as members instead of guests. Use the Azure AD B2B Invitation
Manager APIs to add or invite a user from the partner organization to the host organization as a member.

Filter for guest users in the directory


Convert UserType
It's possible to convert UserType from Member to Guest and vice-versa by using PowerShell. However, the
UserType property represents the user's relationship to the organization. Therefore, you should change this
property only if the relationship of the user to the organization changes. If the relationship of the user changes,
should the user principal name (UPN ) change? Should the user continue to have access to the same resources?
Should a mailbox be assigned? We don't recommend changing the UserType by using PowerShell as an atomic
activity. Also, in case this property becomes immutable by using PowerShell, we don't recommend taking a
dependency on this value.

Remove guest user limitations


There may be cases where you want to give your guest users higher privileges. You can add a guest user to any
role and even remove the default guest user restrictions in the directory to give a user the same privileges as
members.
It's possible to turn off the default limitations so that a guest user in the company directory has the same
permissions as a member user.
Can I make guest users visible in the Exchange Global Address List?
Yes. By default, guest objects aren't visible in your organization's global address list, but you can use Azure Active
Directory PowerShell to make them visible. For details, see Can I make guest objects visible in the global
address list? in Manage guest access in Office 365 Groups.

Next steps
What is Azure AD B2B collaboration?
B2B collaboration user tokens
B2B collaboration user claims mapping
Configure SaaS apps for B2B collaboration
5/16/2019 • 2 minutes to read • Edit Online

Azure Active Directory (Azure AD ) B2B collaboration works with most apps that integrate with Azure AD. In this
section, we walk through instructions for configuring some popular SaaS apps for use with Azure AD B2B.
Before you look at app-specific instructions, here are some rules of thumb:
For most of the apps, user setup needs to happen manually. That is, users must be created manually in the
app as well.
For apps that support automatic setup, such as Dropbox, separate invitations are created from the apps.
Users must be sure to accept each invitation.
In the user attributes, to mitigate any issues with mangled user profile disk (UPD ) in guest users, always set
User Identifier to user.mail.

Dropbox Business
To enable users to sign in using their organization account, you must manually configure Dropbox Business to use
Azure AD as a Security Assertion Markup Language (SAML ) identity provider. If Dropbox Business has not been
configured to do so, it cannot prompt or otherwise allow users to sign in using Azure AD.
1. To add the Dropbox Business app into Azure AD, select Enterprise applications in the left pane, and then
click Add.

2. In the Add an application window, enter dropbox in the search box, and then select Dropbox for
Business in the results list.
3. On the Single sign-on page, select Single sign-on in the left pane, and then enter user.mail in the User
Identifier box. (It's set as UPN by default.)

4. To download the certificate to use for Dropbox configuration, select Configure DropBox, and then select
SAML Single Sign On Service URL in the list.
5. Sign in to Dropbox with the sign-on URL from the Single sign-on page.

6. On the menu, select Admin Console.

7. In the Authentication dialog box, select More, upload the certificate and then, in the Sign in URL box,
enter the SAML single sign-on URL.
8. To configure automatic user setup in the Azure portal, select Provisioning in the left pane, select
Automatic in the Provisioning Mode box, and then select Authorize.
After guest or member users have been set up in the Dropbox app, they receive a separate invitation from
Dropbox. To use Dropbox single sign-on, invitees must accept the invitation by clicking a link in it.

Box
You can enable users to authenticate Box guest users with their Azure AD account by using federation that's based
on the SAML protocol. In this procedure, you upload metadata to Box.com.
1. Add the Box app from the enterprise apps.
2. Configure single sign-on in the following order:
a. In the Sign on URL box, ensure that the sign-on URL is set appropriately for Box in the Azure portal. This
URL is the URL of your Box.com tenant. It should follow the naming convention https://.box.com.
The Identifier does not apply to this app, but it still appears as a mandatory field.
b. In the User identifier box, enter user.mail (for SSO for guest accounts).
c. Under SAML Signing Certificate, click Create new certificate.
d. To begin configuring your Box.com tenant to use Azure AD as an identity provider, download the
metadata file and then save it to your local drive.
e. Forward the metadata file to the Box support team, which configures single sign-on for you.
3. For Azure AD automatic user setup, in the left pane, select Provisioning, and then select Authorize.
Like Dropbox invitees, Box invitees must redeem their invitation from the Box app.

Next steps
See the following articles on Azure AD B2B collaboration:
What is Azure AD B2B collaboration?
Dynamic groups and B2B collaboration
B2B collaboration user claims mapping
Office 365 external sharing
Grant locally-managed partner accounts access to
cloud resources using Azure AD B2B collaboration
5/16/2019 • 2 minutes to read • Edit Online

Before Azure Active Directory (Azure AD ), organizations with on-premises identity systems have traditionally
managed partner accounts in their on-premises directory. In such an organization, when you start to move apps
to Azure AD, you want to make sure your partners can access the resources they need. It shouldn't matter
whether the resources are on-premises or in the cloud. Also, you want your partner users to be able to use the
same sign-in credentials for both on-premises and Azure AD resources.
If you create accounts for your external partners in your on-premises directory (for example, you create an
account with a sign-in name of "wmoran" for an external user named Wendy Moran in your partners.contoso.com
domain), you can now sync these accounts to the cloud. Specifically, you can use Azure AD Connect to sync the
partner accounts to the cloud as Azure AD B2B users (that is, users with UserType = Guest). This enables your
partner users to access cloud resources using the same credentials as their local accounts, without giving them
more access than they need.

Identify unique attributes for UserType


Before you enable synchronization of the UserType attribute, you must first decide how to derive the UserType
attribute from on-premises Active Directory. In other words, what parameters in your on-premises environment
are unique to your external collaborators? Determine a parameter that distinguishes these external collaborators
from members of your own organization.
Two common approaches for this are to:
Designate an unused on-premises Active Directory attribute (for example, extensionAttribute1) to use as the
source attribute.
Alternatively, derive the value for UserType attribute from other properties. For example, you want to
synchronize all users as Guest if their on-premises Active Directory UserPrincipalName attribute ends with the
domain @partners.contoso.com.
For detailed attribute requirements, see Enable synchronization of UserType.

Configure Azure AD Connect to sync users to the cloud


After you identify the unique attribute, you can configure Azure AD Connect to sync these users to the cloud as
Azure AD B2B users (that is, users with UserType = Guest). From an authorization point of view, these users are
indistinguishable from B2B users created through the Azure AD B2B collaboration invitation process.
For implementation instructions, see Enable synchronization of UserType.

Next steps
Azure Active Directory B2B collaboration for hybrid organizations
Grant B2B users in Azure AD access to your on-premises applications
For an overview of Azure AD Connect, see Integrate your on-premises directories with Azure Active Directory.
Grant B2B users in Azure AD access to your on-
premises applications
6/13/2019 • 4 minutes to read • Edit Online

As an organization that uses Azure Active Directory (Azure AD ) B2B collaboration capabilities to invite guest users
from partner organizations to your Azure AD, you can now provide these B2B users access to on-premises apps.
These on-premises apps can use SAML -based authentication or Integrated Windows Authentication (IWA) with
Kerberos constrained delegation (KCD ).

Access to SAML apps


If your on-premises app uses SAML -based authentication, you can easily make these apps available to your Azure
AD B2B collaboration users through the Azure portal.
You must do both of the following:
Integrate the SAML app by using the non-gallery application template, as described in Configuring single
sign-on to applications that are not in the Azure Active Directory application gallery. Make sure to note
what you use for the Sign-on URL value.
Use Azure AD Application Proxy to publish the on-premises app, with Azure Active Directory configured
as the authentication source. For instructions, see Publish applications using Azure AD Application Proxy.
When you configure the Internal Url setting, use the sign-on URL that you specified in the non-gallery
application template. In this way, users can access the app from outside the organization boundary.
Application Proxy performs the SAML single sign-on for the on-premises app.

Access to IWA and KCD apps


To provide B2B users access to on-premises applications that are secured with Integrated Windows
Authentication and Kerberos constrained delegation, you need the following components:
Authentication through Azure AD Application Proxy. B2B users must be able to authenticate to the
on-premises application. To do this, you must publish the on-premises app through the Azure AD
Application Proxy. For more information, see Get started with Application Proxy and install the connector
and Publish applications using Azure AD Application Proxy.
Authorization via a B2B user object in the on-premises directory. The application must be able to
perform user access checks, and grant access to the correct resources. IWA and KCD require a user object
in the on-premises Windows Server Active Directory to complete this authorization. As described in How
single sign-on with KCD works, Application Proxy needs this user object to impersonate the user and get a
Kerberos token to the app.
For the B2B user scenario, there are two methods available that you can use to create the guest user objects
that are required for authorization in the on-premises directory:
Microsoft Identity Manager (MIM ) and the MIM management agent for Microsoft Graph.
A PowerShell script. Using the script is a more lightweight solution that does not require MIM.
The following diagram provides a high-level overview of how Azure AD Application Proxy and the generation of
the B2B user object in the on-premises directory work together to grant B2B users access to your on-premises
IWA and KCD apps. The numbered steps are described in detail below the diagram.

1. A user from a partner organization (the Fabrikam tenant) is invited to the Contoso tenant.
2. A guest user object is created in the Contoso tenant (for example, a user object with a UPN of
guest_fabrikam.com#EXT#@contoso.onmicrosoft.com).
3. The Fabrikam guest is imported from Contoso through MIM or through the B2B PowerShell script.
4. A representation or “footprint” of the Fabrikam guest user object (Guest#EXT#) is created in the on-premises
directory, Contoso.com, through MIM or through the B2B PowerShell script.
5. The guest user accesses the on-premises application, app.contoso.com.
6. The authentication request is authorized through Application Proxy, using Kerberos constrained delegation.
7. Because the guest user object exists locally, the authentication is successful.
Lifecycle management policies
You can manage the on-premises B2B user objects through lifecycle management policies. For example:
You can set up multi-factor authentication (MFA) policies for the Guest user so that MFA is used during
Application Proxy authentication. For more information, see Conditional Access for B2B collaboration users.
Any sponsorships, access reviews, account verifications, etc. that are performed on the cloud B2B user applies
to the on-premises users. For example, if the cloud user is deleted through your lifecycle management policies,
the on-premises user is also deleted by MIM Sync or through Azure AD Connect sync. For more information,
see Manage guest access with Azure AD access reviews.
Create B2B guest user objects through MIM
For information about how to use MIM 2016 Service Pack 1 and the MIM management agent for Microsoft
Graph to create the guest user objects in the on-premises directory, see Azure AD business-to-business (B2B )
collaboration with Microsoft Identity Manager (MIM ) 2016 SP1 with Azure Application Proxy.
Create B2B guest user objects through a script (Preview)
There’s a PowerShell sample script available that you can use as a starting point to create the guest user objects in
your on-premises Active Directory.
You can download the script and the Readme file from the Download Center. Choose the Script and Readme to
pull Azure AD B2B users on-prem.zip file.
Before you use the script, make sure that you review the prerequisites and important considerations in the
associated Readme file. Also, understand that the script is made available only as a sample. Your development
team or a partner must customize and review the script before you run it.

License considerations
Make sure that you have the correct Client Access Licenses (CALs) for external guest users who access on-
premises apps. For more information, see the "External Connectors" section of Client Access Licenses and
Management Licenses. Consult your Microsoft representative or local reseller regarding your specific licensing
needs.

Next steps
Azure Active Directory B2B collaboration for hybrid organizations
For an overview of Azure AD Connect, see Integrate your on-premises directories with Azure Active
Directory.
Leave an organization as a guest user
6/13/2019 • 2 minutes to read • Edit Online

An Azure Active Directory (Azure AD ) B2B guest user can decide to leave an organization at any time if they no
longer need to use apps from that organization or maintain any association. A user can leave an organization on
their own, without having to contact an administrator.

NOTE
A guest user can't leave an organization if their account is disabled in either the home tenant or the resource tenant. If their
account is disabled, the guest user will need to contact the tenant admin, who can either delete the guest account or enable
the guest account so the user can leave the organization.

Leave an organization
To leave an organization, follow these steps.
1. Go to your Access Panel Profile page by doing one of the following steps:
In the Azure portal, click your name in the upper right and select View account.
Open your Access Panel, click your name in the upper right, and next to Organizations, select the
settings icon (gear).

NOTE
If you’re not already signed in to the organization you want to leave, under Organizations, click the Sign in to
leave organization link next to the organization’s name. After you’re signed in, click your name again in the upper
right and next to Organizations, select the settings icon (gear).

2. Under Organizations, find the organization that you want to leave, and select Leave organization.
3. When asked to confirm, select Leave.

Account removal
When a user leaves an organization, the user account is "soft deleted" in the directory. By default, the user object
moves to the Deleted users area in Azure AD but isn't permanently deleted for 30 days. This soft deletion enables
the administrator to restore the user account (including groups and permissions), if the user makes a request to
restore the account within the 30-day period.
If desired, a tenant administrator can permanently delete the account at any time during the 30-day period. To do
this:
1. In the Azure portal, select Azure Active Directory.
2. Under Manage, select Users.
3. Select Deleted users.
4. Select the check box next to a deleted user, and then select Delete permanently.
If you permanently delete a user, this action is irrevocable.

NOTE
For information about viewing or deleting personal data, see Azure Data Subject Requests for the GDPR. For more
information about GDPR, see the GDPR section of the Service Trust portal.

Next steps
For an overview of Azure AD B2B, see What is Azure AD B2B collaboration?
Auditing and reporting a B2B collaboration user
5/16/2019 • 2 minutes to read • Edit Online

With guest users, you have auditing capabilities similar to with member users.

Access reviews
You can use access reviews to periodically verify whether guest users still need access to your resources. The
Access reviews feature is available in Azure Active Directory under Manage > Organizational
Relationships. (You can also search for "access reviews" from All services in the Azure portal.) To learn how to
use access reviews, see Manage guest access with Azure AD access reviews.

Audit logs
The Azure AD audit logs provide records of system and user activities, including activities initiated by guest users.
To access audit logs, in Azure Active Directory, under Monitoring, select Audit logs. Here's an example of the
invitation and redemption history of invitee Sam Oogle:

You can dive into each of these events to get the details. For example, let's look at the acceptance details.
You can also export these logs from Azure AD and use the reporting tool of your choice to get customized reports.
Next steps
B2B collaboration user properties
Troubleshooting Azure Active Directory B2B
collaboration
9/13/2019 • 4 minutes to read • Edit Online

Here are some remedies for common problems with Azure Active Directory (Azure AD ) B2B collaboration.

I’ve added an external user but do not see them in my Global Address
Book or in the people picker
In cases where external users are not populated in the list, the object might take a few minutes to replicate.

A B2B guest user is not showing up in SharePoint Online/OneDrive


people picker
The ability to search for existing guest users in the SharePoint Online (SPO ) people picker is OFF by default to
match legacy behavior.
You can enable this feature by using the setting 'ShowPeoplePickerSuggestionsForGuestUsers' at the tenant and
site collection level. You can set the feature using the Set-SPOTenant and Set-SPOSite cmdlets, which allow
members to search all existing guest users in the directory. Changes in the tenant scope do not affect already
provisioned SPO sites.

Invitations have been disabled for directory


If you are notified that you do not have permissions to invite users, verify that your user account is authorized to
invite external users under Azure Active Directory > User settings > External users > Manage external
collaboration settings:

If you have recently modified these settings or assigned the Guest Inviter role to a user, there might be a 15-60
minute delay before the changes take effect.

The user that I invited is receiving an error during redemption


Common errors include:
Invitee’s Admin has disallowed EmailVerified Users from being created in their tenant
When inviting users whose organization is using Azure Active Directory, but where the specific user’s account does
not exist (for example, the user does not exist in Azure AD contoso.com). The administrator of contoso.com may
have a policy in place preventing users from being created. The user must check with their admin to determine if
external users are allowed. The external user’s admin may need to allow Email Verified users in their domain (see
this article on allowing Email Verified Users).

External user does not exist already in a federated domain


If you are using federation authentication and the user does not already exist in Azure Active Directory, the user
cannot be invited.
To resolve this issue, the external user’s admin must synchronize the user’s account to Azure Active Directory.

How does ‘#’, which is not normally a valid character, sync with Azure
AD?
“#” is a reserved character in UPNs for Azure AD B2B collaboration or external users, because the invited account
[email protected] becomes user_contoso.com#EXT#@fabrikam.onmicrosoft.com. Therefore, # in UPNs coming
from on-premises aren't allowed to sign in to the Azure portal.

I receive an error when adding external users to a synchronized group


External users can be added only to “assigned” or “Security” groups and not to groups that are mastered on-
premises.

My external user did not receive an email to redeem


The invitee should check with their ISP or spam filter to ensure that the following address is allowed:
[email protected]

I notice that the custom message does not get included with invitation
messages at times
To comply with privacy laws, our APIs do not include custom messages in the email invitation when:
The inviter doesn’t have an email address in the inviting tenant
When an appservice principal sends the invitation
If this scenario is important to you, you can suppress our API invitation email, and send it through the email
mechanism of your choice. Consult your organization’s legal counsel to make sure any email you send this way
also complies with privacy laws.

You receive an “AADSTS65005” error when you try to log in to an


Azure resource
A user who has a guest account cannot log on, and is receiving the following error message:

AADSTS65005: Using application 'AppName' is currently not supported for your organization contoso.com because
it is in an unmanaged state. An administrator needs to claim ownership of the company by DNS validation of
contoso.com before the application AppName can be provisioned.

The user has an Azure user account and is a viral tenant who has been abandoned or unmanaged. Additionally,
there are no global or company administrators in the tenant.
To resolve this problem, you must take over the abandoned tenant. Refer to Take over an unmanaged directory as
administrator in Azure Active Directory. You must also access the internet-facing DNS for the domain suffix in
question in order to provide direct evidence that you are in control of the namespace. After the tenant is returned
to a managed state, please discuss with the customer whether leaving the users and verified domain name is the
best option for their organization.

A guest user with a just-in-time or "viral" tenant is unable to reset their


password
If the identity tenant is a just-in-time (JIT) or viral tenant (meaning it's a separate, unmanaged Azure tenant), only
the guest user can reset their password. Sometimes an organization will take over management of viral tenants
that are created when employees use their work email addresses to sign up for services. After the organization
takes over a viral tenant, only an administrator in that organization can reset the user's password or enable SSPR.
If necessary, as the inviting organization, you can remove the guest user account from your directory and resend
an invitation.

Next steps
Get support for B2B collaboration
Azure Active Directory B2B collaboration API and
customization
5/16/2019 • 2 minutes to read • Edit Online

We've had many customers tell us that they want to customize the invitation process in a way that works best for
their organizations. With our API, you can do just that. https://developer.microsoft.com/graph/docs/api-
reference/v1.0/resources/invitation

Capabilities of the invitation API


The API offers the following capabilities:
1. Invite an external user with any email address.

"invitedUserDisplayName": "Sam"
"invitedUserEmailAddress": "[email protected]"

2. Customize where you want your users to land after they accept their invitation.

"inviteRedirectUrl": "https://myapps.microsoft.com/"

3. Choose to send the standard invitation mail through us

"sendInvitationMessage": true

with a message to the recipient that you can customize

"customizedMessageBody": "Hello Sam, let's collaborate!"

4. And choose to cc: people you want to keep in the loop about your inviting this collaborator.
5. Or completely customize your invitation and onboarding workflow by choosing not to send notifications
through Azure AD.

"sendInvitationMessage": false

In this case, you get back a redemption URL from the API that you can embed in an email template, IM, or
other distribution method of your choice.
6. Finally, if you are an admin, you can choose to invite the user as member.

"invitedUserType": "Member"

Authorization model
The API can be run in the following authorization modes:
App + User mode
In this mode, whoever is using the API needs to have the permissions to be create B2B invitations.
App only mode
In app only context, the app needs the User.Invite.All scope for the invitation to succeed.
For more information, refer to: https://developer.microsoft.com/graph/docs/authorization/permission_scopes

PowerShell
You can use PowerShell to add and invite external users to an organization easily. Create an invitation using the
cmdlet:

New-AzureADMSInvitation

You can use the following options:


-InvitedUserDisplayName
-InvitedUserEmailAddress
-SendInvitationMessage
-InvitedUserMessageInfo
Invitation status
After you send an external user an invitation, you can use the Get-AzureADUser cmdlet to see if they've accepted
it. The following properties of Get-AzureADUser are populated when an external user is sent an invitation:
UserState indicates whether the invitation is PendingAcceptance or Accepted.
UserStateChangedOn shows the timestamp for the latest change to the UserState property.
You can use the Filter option to filter the results by UserState. The example below shows how to filter results to
show only users who have a pending invitation. The example also shows the Format-List option, which lets you
specify the properties to display.

Get-AzureADUser -Filter "UserState eq 'PendingAcceptance'" | Format-List -Property


DisplayName,UserPrincipalName,UserState,UserStateChangedOn

NOTE
Make sure you have the latest version of the AzureAD PowerShell module or AzureADPreview PowerShell module.

See also
Check out the invitation API reference in https://developer.microsoft.com/graph/docs/api-
reference/v1.0/resources/invitation.

Next steps
What is Azure AD B2B collaboration?
The elements of the B2B collaboration invitation email
B2B collaboration invitation redemption
Add B2B collaboration users without an invitation
Azure Active Directory B2B collaboration FAQs
6/20/2019 • 8 minutes to read • Edit Online

These frequently asked questions (FAQs) about Azure Active Directory (Azure AD ) business-to-business (B2B )
collaboration are periodically updated to include new topics.
Can we customize our sign-in page so it's more intuitive for our B2B collaboration guest users?
Absolutely! See our blog post about this feature. For more information about how to customize your
organization's sign-in page, see Add company branding to sign in and Access Panel pages.
Can B2B collaboration users access SharePoint Online and OneDrive?
Yes. However, the ability to search for existing guest users in SharePoint Online by using the people picker is Off
by default. To turn on the option to search for existing guest users, set
ShowPeoplePickerSuggestionsForGuestUsers to On. You can turn this setting on either at the tenant level or
at the site collection level. You can change this setting by using the Set-SPOTenant and Set-SPOSite cmdlets. With
these cmdlets, members can search all existing guest users in the directory. Changes in the tenant scope don't
affect SharePoint Online sites that have already been provisioned.
Is the CSV upload feature still supported?
Yes. For more information about using the .csv file upload feature, see this PowerShell sample.
How can I customize my invitation emails?
You can customize almost everything about the inviter process by using the B2B invitation APIs.
Can guest users reset their multi-factor authentication method?
Yes. Guest users can reset their multi-factor authentication method the same way that regular users do.
Which organization is responsible for multi-factor authentication licenses?
The inviting organization performs multi-factor authentication. The inviting organization must make sure that the
organization has enough licenses for their B2B users who are using multi-factor authentication.
What if a partner organization already has multi-factor authentication set up? Can we trust their multi-factor
authentication, and not use our own multi-factor authentication?
This feature is currently not supported. If access to your organization's resources requires multi-factor
authentication, the partner organization will need to register for multi-factor authentication in your (the inviting)
organization.
How can I use delayed invitations?
An organization might want to add B2B collaboration users, provision them to applications as needed, and then
send invitations. You can use the B2B collaboration invitation API to customize the onboarding workflow.
Can I make guest users visible in the Exchange Global Address List?
Yes. Guest objects aren't visible in your organization's global address list (GAL ) by default, but you can use Azure
Active Directory PowerShell to make them visible. See Can I make guest objects visible in the global address list?
Can I make a guest user a limited administrator?
Absolutely. For more information, see Adding guest users to a role.
Does Azure AD B2B collaboration allow B2B users to access the Azure portal?
Unless a user is assigned the role of limited administrator, B2B collaboration users won't require access to the
Azure portal. However, B2B collaboration users who are assigned the role of limited administrator can access the
portal. Also, if a guest user who isn't assigned one of these admin roles accesses the portal, the user might be able
to access certain parts of the experience. The guest user role has some permissions in the directory.
Can I block access to the Azure portal for guest users?
Yes! When you configure this policy, be careful to avoid accidentally blocking access to members and admins. To
block a guest user's access to the Azure portal, use a Conditional Access policy in the Windows Azure classic
deployment model API:
1. Modify the All Users group so that it contains only members.

2. Create a dynamic group that contains guest users.

3. Set up a Conditional Access policy to block guest users from accessing the portal, as shown in the following
video:
Does Azure AD B2B collaboration support multi-factor authentication and consumer email accounts?
Yes. Multi-factor authentication and consumer email accounts are both supported for Azure AD B2B collaboration.
Do you support password reset for Azure AD B2B collaboration users?
If your Azure AD tenant is the home directory for a user, you can reset the user's password from the Azure portal.
But you can't directly reset a password for a guest user who signs in with an account that's managed by another
Azure AD directory or external identity provider. Only the guest user or an administrator in the user’s home
directory can reset the password. Here are some examples of how password reset works for guest users:
Guest users who sign in with a Microsoft account (for example [email protected]) can reset their own
passwords using Microsoft account self-service password reset (SSPR ). See How to reset your Microsoft
account password.
Guest users who sign in with a Google account or another external identity provider can reset their own
passwords using their identity provider’s SSPR method. For example, a guest user with the Google account
[email protected] can reset their password by following the instructions in Change or reset your
password.
If the identity tenant is a just-in-time (JIT) or "viral" tenant (meaning it's a separate, unmanaged Azure tenant),
only the guest user can reset their password. Sometimes an organization will take over management of viral
tenants that are created when employees use their work email addresses to sign up for services. After the
organization takes over a viral tenant, only an administrator in that organization can reset the user's password
or enable SSPR. If necessary, as the inviting organization, you can remove the guest user account from your
directory and resend an invitation.
If the guest user's home directory is your Azure AD tenant, you can reset the user's password. For example,
you might have created a user or synced a user from your on-premises Active Directory and set their UserType
to Guest. Because this user is homed in your directory, you can reset their password from the Azure portal.
Does Microsoft Dynamics 365 provide online support for Azure AD B2B collaboration?
Yes, Dynamics 365 (online) supports Azure AD B2B collaboration. For more information, see the Dynamics 365
article Invite users with Azure AD B2B collaboration.
What is the lifetime of an initial password for a newly created B2B collaboration user?
Azure AD has a fixed set of character, password strength, and account lockout requirements that apply equally to
all Azure AD cloud user accounts. Cloud user accounts are accounts that aren't federated with another identity
provider, such as
Microsoft account
Facebook
Active Directory Federation Services
Another cloud tenant (for B2B collaboration)
For federated accounts, password policy depends on the policy that is applied in the on-premises tenancy and the
user's Microsoft account settings.
An organization might want to have different experiences in their applications for tenant users and guest users.
Is there standard guidance for this? Is the presence of the identity provider claim the correct model to use?
A guest user can use any identity provider to authenticate. For more information, see Properties of a B2B
collaboration user. Use the UserType property to determine user experience. The UserType claim isn't currently
included in the token. Applications should use the Graph API to query the directory for the user, and to get the
UserType.
Where can I find a B2B collaboration community to share solutions and to submit ideas?
We're constantly listening to your feedback, to improve B2B collaboration. Please share your user scenarios, best
practices, and what you like about Azure AD B2B collaboration. Join the discussion in the Microsoft Tech
Community.
We also invite you to submit your ideas and vote for future features at B2B Collaboration Ideas.
Can we send an invitation that is automatically redeemed, so that the user is just “ready to go”? Or does the user
always have to click through to the redemption URL?
You can invite other users in the partner organization by using the UI, PowerShell scripts, or APIs. You can then
send the guest user a direct link to a shared app. In most cases, there's no longer a need to open the email
invitation and click a redemption URL. See Azure Active Directory B2B collaboration invitation redemption.
How does B2B collaboration work when the invited partner is using federation to add their own on-premises
authentication?
If the partner has an Azure AD tenant that is federated to the on-premises authentication infrastructure, on-
premises single sign-on (SSO ) is automatically achieved. If the partner doesn't have an Azure AD tenant, an Azure
AD account is created for new users.
I thought Azure AD B2B didn't accept gmail.com and outlook.com email addresses, and that B2C was used for
those kinds of accounts?
We are removing the differences between B2B and business-to-consumer (B2C ) collaboration in terms of which
identities are supported. The identity used isn't a good reason to choose between using B2B or using B2C. For
information about choosing your collaboration option, see Compare B2B collaboration and B2C in Azure Active
Directory.
What applications and services support Azure B2B guest users?
All Azure AD -integrated applications can support Azure B2B guest users, but they must use an endpoint set up as
a tenant to authenticate guest users. You might also need to customize the claims in the SAML token that is issued
when a guest user authenticates to the app.
Can we force multi-factor authentication for B2B guest users if our partners don't have multi-factor
authentication?
Yes. For more information, see Conditional Access for B2B collaboration users.
In SharePoint, you can define an "allow" or "deny" list for external users. Can we do this in Azure?
Yes. Azure AD B2B collaboration supports allow lists and deny lists.
What licenses do we need to use Azure AD B2B?
For information about what licenses your organization needs to use Azure AD B2B, see Azure Active Directory
B2B collaboration licensing guidance.
Next steps
What is Azure AD B2B collaboration?
Getting support for B2B collaboration
5/16/2019 • 2 minutes to read • Edit Online

You’ve read through the documentation, you’ve done the right things, but still can’t get something to work? Open
a support ticket (requires a support plan):
1. In the Azure portal, navigate to the Help and Support blade, and select New Support Request:
Issue type: Technical
Subscription: Choose affected subscription
Service: Active Directory
Support Plan: Choose relevant support plan

2. Describe your problem:


Choose the appropriate severity that reflects you needs.
Choose Problem Type as User and Group Management
Choose Category as Adding Users (B2B )
Include any error messages such as CorrelationID, affected users, and so on.
3. For a support representative to contact you for further troubleshooting, add your contact information.

You might also like