Introduction
If you have resources deployed to a Microsoft Azure tenant it is likely that at some time there will be a requirement to share resource as part of a collaboration with an external entity such as a customer, a business partner, supplier, or company subsidiary. The extent of the collaboration could range from a simple sharing of a single file or OneDrive folder to a more comprehensive integration with an external entity including sharing of an HR System, ITSM Service, or line of business applications. Microsoft provides a number of options for collaborating with external entities including Azure AD B2B Collaboration, Azure AD B2C, and Azure AD Direct Federation.
The focus of this case study is to provide practical guidance for planning and implementation of the Azure AD B2B Collaboration scenario. It is based on the learnings from a recent B2B Collaboration implementation for a large Australian retail company incorporating some 15,000 B2B accounts. Code samples are provided for many of the key activities, but these will need to be modified to meet the specific details and requirements of the individual Microsoft Azure AD Tenancy.
The key topics covered in this paper are:
When to use B2B Collaboration
How to configure B2B Guest Accounts and associated attributes
Key differences between Guest Accounts and Member Accounts
Which methods to use for Guest Account redemption
Automated provisioning
Lifecycle and Governance of B2B Accounts
How to secure Guest Accounts
Prerequisites
Early implementations of Microsoft Azure AD B2B Collaboration supported the use of an “unmanaged” Azure AD account, however this method is now being deprecated so Azure customers should be looking to migrate away from this model.
As with a number of Microsoft Azure services B2B Collaboration is frequently being updated but as of time of writing the following B2B scenarios are supported:
1. Azure AD Tenant-to-Tenant
2. Personal Microsoft Account (MSA)
3. Google Federation
4. Direct Federation
5. Email one-time passcode authentication
This remainder of this article will focus on Scenario 1. Scenarios 2-5 require additional configuration which is already covered in detail by Microsoft in separate articles. The Google scenario is really a special case of the Direct Federation.
Note that in most cases the B2B Collaboration requires a Microsoft managed email account. If you need to incorporate non-Microsoft accounts into a B2B Collaboration, and there is no direct federation established, then you need to enable the email one-time passcode authentication.
B2B Guest Accounts
At the core of Azure B2B Collaboration is the concept of the Guest account. For each user account needing to participate in a B2B collaboration, a corresponding Guest account must be created in the Azure Inviting Tenant.
B2B Guest accounts, although not used for direct login, have a number of characteristics in common with user accounts:
Guest accounts share the same schema as user accounts and have associated attributes. As a minimum Guest accounts have a UPN, displayName, and email related attributes, however, additional attributes can be added such as first name, last name, employee ID. These entries can become important when using Guest accounts to access SaaS applications configured in the resource tenant e.g. to pass as claims in a SAML assertion or OpenID Connect token. They can also be used to store security related information e.g. telephone number for MFA One-time passcode.
Guest accounts can be added to groups and can be given role assignments. Just as with user accounts, they can be added to security groups (static or dynamic) which are used to provide access to applications and resources. By default, Guest accounts become members of the “All Users” group upon redemption of the guest invitation so it is important to consider how this group is used within an Azure tenancy.
Conditional Access Policies can be applied to Guest accounts. As with user accounts they can be added to scopes used to manage key security policies such as MFA, login timeouts and browser persistence.
Likewise there are a few important differences:
Guest accounts have a different UPN format. User accounts have the format aaa.bbb@xyz.com where xyz.com is a verified domain. Guest accounts use the format aaa.bbb_xyz.com@#EXT#<initialdomainname>.onmicrosoft.com. However, the EXT UPN is just a user-friendly reminder to the admin of whom the Guest user referred to. Although the UPN is stored using the #EXT# format it is not required to make the B2B collaboration work. For example, when using a B2B UPN in a SAML claim for a SaaS it is revealed as aaa.bbb@xyz.com so there is no need to apply a claims transformation. However, it is useful to note that the #EXT# format is used when dealing with Guest Accounts programmatically.
Guest accounts do not normally have a password credential. As they are not used for direct login these accounts should not have passwords. Therefore, if converting from a user account to a guest account, it is important to remove the password to prevent direct login to the inviting tenant.
Guest Account Identity Lifecycle Management and Governance
As discussed above, Guest accounts have privileges similar to standard user accounts so should be incorporated into a company’s identity lifecycle and governance processes :
Guest accounts should follow a standard joiner, mover, leaver lifecycle process. When Guests are no longer active or have changed roles due to lifecycle events they should be removed/updated in Azure to reflect the changed status. Guest accounts incur a license (equivalent to 20% of standard user) so there are financial incentives as well as security considerations for managing the lifecycle of these accounts.
Where Guest accounts are members of privileged groups and roles there should be regular access reviews conducted to ensure that any entitlements have been correctly assigned and are still required.
Principles of least privilege should apply. By default Guest users have similar access to member accounts which means they can view certain Azure AD properties. If this access is not genuinely required, then the access should be restricted by modifying the Guest access via the External Collaboration Settings in the Azure Portal.
As of June 2021, Microsoft added a new Guest User permission level know as Restricted Access. With this permission level, guests can view only their own user profile. Permission to view other users denied. Restricted access also restricts guest users from seeing the membership of groups they're in.
As Guest accounts and associated Member accounts are usually managed by different entities (organisations) this creates additional challenges for IAM Security teams. For the implementation that this case study is based on SailPoint’s Identity IQ (Inviting Tenant) and IdentityNow (Home Tenant) products were used for automation of account provisioning and identity governance. SailPoint connector technology has out-of-the-box capability to perform operations on Guest Accounts.
It is possible to delegate permissions to specific users in the home tenant by adding them to the “Guest Inviter role”.
However, this can become cumbersome if there are multiple B2B Collaborations with external organisations. There is also the consideration of where the identity governance activities should occur? It may not be practical to conduct access reviews in the inviting tenant (where the Guest accounts reside) as access reviews tend to be performed people with good working knowledge of the reviewee’s role in an organisation e.g. line managers or product owners in the home tenant.
The key point here is that if the collaboration is to include potentially a large number of accounts then careful planning is required to achieve the desired level of cooperation between the Inviting Azure Tenant and the external B2B organisation.
Creating Guest Accounts
Guest Accounts can be created directly via the Azure portal, however if dealing with more than a handful of accounts then it will be beneficial to automate using PowerShell or Microsoft Graph.
If the invited users are from another Azure Tenant ensure that the member accounts exist before creating the Guest Accounts[1].
Note that the Azure member accounts do not have to be backed by a mailbox. In the example below we are not sending an invitation message as we will redeem the invitation via a direct link (more on this later)
[1] Azure AD will allow creation of the guest account without the associated member account, but you may experience redemption issues when using the Direct Link method
#Users AzureAD Module
Connect-AzAccount
#Create Single Guest
New-AzureADMSInvitation -InvitedUserDisplayName "aaa.bbb" -InvitedUserEmailAddress "aaa.bbb@xyz.com.au" -InviteRedirectURL "https://myapps.microsoft.com" -SendInvitationMessage $falseAfter creating the Guest Account, we may want to add some attributes (including extended attributes). It is recommended to wait a period before adding the attributes to ensure that the changes have been committed.
Connect-AzureAD
#Fetch the guest user
$GuestUser = Get-AzureADUser -Filter "otherMails/any (c:c eq 'aaa.bbb@xyz.com.au')"
#Update user GivenName and Surname
Set-AzureADUser -ObjectId $GuestUser.ObjectID -Givenname "aaa" -Surname "bbb"
#Update custom extension e.g. sAMAccountName
Set-AzureADUserExtension -ObjectId $GuestUser.ObjectID -ExtensionName "extension_<tenant id>_sAMAccountName" -ExtensionValue $Entry.sam
#Update employee ID attribute
Set-AzureADUserExtension -ObjectId $GuestUser.ObjectID -ExtensionName "employeeId" -ExtensionValue "12345"To get a list of extension attributes from your Azure tenant you can use the following
Connect-AzureAD
# Retrieve all extension attributes
Get-AzureADApplication | Get-AzureADApplicationExtensionPropertyIf you wish to use the UPN for managing the Guest Account then it can be derived from the email entry as follows. Note that the MSOL-Service module is required for this ..
# Requires AzureAD and MSOL-Service Modules
Connect-AzureAD
Connect-MsolService
$Users = import-csv -path ".\Guest_Account_Input_File.csv"
write-output "Total users: $($Users.count)"
# Get initial (onmicrosoft) Domain
$initialdomain = ((get-msoldomain | Where-Object {$_.isinitial -eq $true}).name)
Foreach ($Entry in $users) {
Write-Host "$($Entry.email)"
#Get guest UPN
$splitUPN= $Entry.email.Split("@")
$guestUPN = $splitUPN[0] +"_"+ $splitUPN[1] + "#EXT#@"+$initialDomain
}Redeeming Guest Invitations
In order for a Guest Account to access resources in the inviting tenant the user must first redeem the invitation. The guest redemption is a one-off process and takes the user through a mandatory consent experience. Microsoft support a few ways to redeem the invitation
Guest Account Authentication Flow
As part of the invitation redemption the user is driven through the consent experience. This cannot be bypassed, and the user must agree to the terms and conditions before the guest account can be used. After this point the status will change to “Invitation Accepted=Yes” in the user object in the Azure Portal. If the home tenant organisation is using the Azure Access Portal (myapplications.microsoft.com) the user will now see 2 Organisations in the Portal and is able to navigate between the two.
Note that the user is able to delete the guest organisation from the portal. If this happens (accidently) the guest account will move into a deleted state in the inviting tenant. The account will need to be restored or a new invitation issued in order to re-activate the account.
After the account is active the user is able to access and resources they have been assigned to in the inviting tenant. The authentication flow is as follows:
User selects e resource e.g. <inviting company>.salesforce.com or selects and application from the Access Portal.
Resource directs the user to the configured Identity Provider (IdP). In this case it is the inviting tenant.
IdP sees that it is an external account and redirects to the users home tenant
The home tenant authenticates the user and returns the Id token to the inviting tenant.
The inviting tenant applies any Conditional Access policies to the account e.g. MFA
The inviting tenant issues and access token for the guest account and sends to the resource.
Access is granted by the resource.
Tracking Guest Invitations
Once the Guest accounts have been created and users have been invited into the tenant it is possible to view the status of the invitation through via the user’s profile in the Azure portal.
The “invitation accepted” will show the status yes or no. It is also possible to get the status through Powershell via the “userState” attribute for the Guest user object. The following script provides a report on all Guest accounts for the inviting tenant.
# Specify CSV path. Import CSV file and assign it to a variable.
$userList = Import-Csv -Path '.\Guest_Account_Analysis.csv'
# Establish the output array
$outList = @()
#$initialdomain = ((get-msoldomain | Where-Object {$_.isinitial -eq $true}).name)
$initialdomain = '<initialdomainname>.onmicrosoft.com'
foreach ($user in $userList)
{
Write-Host "$($user.email)"
$splitUPN= $user.email.Split("@")
$guestUPN = $splitUPN[0] +"_"+ $splitUPN[1] + "#EXT#@"+$initialDomain
$filter = "userPrincipalName eq '" + $guestUPN + "'"
# Add the objectID to each user object
$user = $user | Select-Object email,guestupn,usertype,userState,createdDateTime
$user.guestupn = $guestupn
$guest = (Get-AzureADUser -Filter "$filter")
#$properties = get-azureaduser -ObjectId $user.objectID | Select-Object -Property userState,userType
$user.userType = $guest.userType
$user.userState = $guest.userState
$user.createdDateTime = (get-msoluser -objectid $guest.objectid).whenCreated
# Add the user to the output array
$outList += $user
}
# Write the output array back out to a CSV
$outList | Export-Csv -Path '.\Guest_Account_Analysis_status.csv' -NoTypeInformationSecuring Guest Accounts
As discussed earlier B2B Guest accounts behave just like normal user accounts and are potentially a lower trust level as they are originating from an external tenant. There are a few ways to further secure these accounts.
Limit guest accounts access
Enforce Multi-factor Authentication.
Apply Azure Conditional Access Policies
Limiting guest accounts access
Guest account access can be restricted through the Azure admin Portal by specifying the required guest user access. Security best practice would be to select the most restrictive access unless there are requirements to configure otherwise.
Multi-Factor Authentication (MFA)
B2B Guest accounts can be configured for MFA in the same way that it is applied to standard user accounts. That is, MFA can be applied at the tenant, app or individual guest level.
Microsoft’s recommendation regarding MFA for B2B users is to “always require MFA in the inviting tenant[1]”. This can potentially lead to a double-MFA situation if policies are also enabled in the home tenant. For this reason, it is recommended to look at the whole user experience to ensure that they do not receive excessive prompts for authentication when engaging in B2B collaboration.
To check the MFA status of a Guest account ..
Connect-MSOLService
Get-MsolUser -All | ? {$_.UserType -eq "Guest"} | select-object DisplayName,UserPrincipalName,@{N="MFA Status"; E={if( $_.StrongAuthenticationRequirements.State -ne $null) {$_.StrongAuthenticationRequirements.State} else { "Disabled"}}} | Export-Csv -NoTypeInformation .\mfastatus.csvAzure Conditional Access Policies
In addition to applying MFA policies other conditional access policies can be used to manage Guest accounts; not only to control access but also to manage the user experience….
Microsoft have included Session based conditional access policies which can be used to manage the security token lifetime and browser persistence. Consider using conditional policies based on the risk profile e.g. for guest accounts with privileged access to an application consider removing the browser persistency and increase the sign-in frequency.
Comments