Several use cases<\/strong> can be applied, including time-bound collaboration with partners<\/strong>, external service providers, suppliers or B2B customers.<\/p>\n Additionally, it is common to observe continuous collaboration between subsidiaries<\/strong> of the same group that have access to the resources and data of the company whilst not necessarily requiring to share the same Information Systems.<\/p>\n Historically, collaboration could be achieved in several ways. However, collaboration also comes with certain disadvantages:<\/p>\n Today, using Azure AD B2B allows two or more entities to collaborate within the host company’s Azure tenant<\/strong>. \u00a0Shared resources can be apps, documents, SharePoint sites, OneDrive, or Teams teams.<\/p>\n In effect, the Azure B2B solution allows an external user to access the host company tenant through their regular account by<\/strong> creating a “guest” identity within the company’s Azure Active Directory (AAD).<\/p>\n The “client” tenant then fully or partially trusts the “external” tenant for authentication via a token exchange mechanism.<\/p>\n There are three native possibilities for creating a “guest” identity:<\/p>\n \u00a0<\/p>\n Figure 1 – Native Operation: Authentication and Identity Creation<\/em><\/p>\n \u00a0<\/p>\n At the level of the host tenant, the owner can choose to authorize the sharing of data to external users while also being able to administer guest accounts (creation, deactivation, deletion etc.).<\/p>\n A direct benefit of this solution is the ease of use<\/strong> for users who are familiar with Microsoft environments.<\/p>\n The second advantage is the cost of the solution<\/strong>. A “guest” identity has a licensing cost whereby up to a ceiling of 50,000 “guest” identities, their license is free. Beyond this and depending on the company’s subscriptions, a license may cost between \u20ac0.003 and \u20ac0.015 \/ month \/ user, which is then added on to a fixed fee of \u20ac0.029 for each multi-factor authentication attempt. This pricing policy is out of step with the usual price of an M365 license, which is between \u20ac10 and \u20ac50 \/ month \/ user depending on the license plan.<\/p>\n \u00a0<\/p>\n Azure AD B2B introduces several factors that can lead to risk<\/strong>:<\/p>\n These factors create risks for the company’s data since the “guest” identity may have rights to a significant number of documents and information about its host owner.<\/p>\n We can consider two triggering events for the different threat scenarios:<\/p>\n An attacker would then have the opportunity to:<\/p>\n \u00a0<\/p>\n The first step is to cut off access to the Azure portal<\/strong> to non-administrator employees of the company so that it is no longer a vector for creating “invited” identities.<\/p>\n Figure 2 – Restricting access to the Azure AD console<\/em><\/p>\n \u00a0<\/p>\n It should be noted that it is also possible to restrict the population who can invite external users to collaborate<\/strong>. However, this will not be applicable to all companies – especially those wishing to decentralize the management of this population. The idea of restricting this population forces the creation of a service dedicated to the creation of these identities. This goes against the very principle of this service, which is to leave it in the hands of the user.<\/p>\n Finally, there is a feature to apply constraints to the email addresses of “guest” identities<\/strong>, via white-listing or domain name blacklisting. However, before embarking on this action, it is necessary to consider the complexity of its implementation and the potential low level of associated risk reduction.<\/p>\n It is also possible to restrict what can be accessed<\/strong> by the invited identities, so that they are unable to retrieve a large volume of information on the host tenant.<\/p>\n Figure 3 – Restrict access for “guest” identities<\/em><\/p>\n \u00a0<\/p>\n The multi-factor authentication (MFA)<\/strong> mechanism for a “guest” identity is almost native and reduces the risk of spoofing by an attacker. It is also possible to set up a conditional access policy<\/strong> that specifically targets these “guest” identities.<\/p>\n \u00a0<\/p>\n Figure 4 – Multi-Factor Authentication<\/em><\/p>\n \u00a0<\/p>\n However, challenges can still complicate this operation and need to be considered:<\/p>\n \u00a0<\/p>\n The major complexity of the Azure AD B2B solution is the lack of a mechanism for managing “guest” identities<\/strong>. Users are therefore the main actors<\/strong> of the management strategy and must be informed at the right level by emphasizing:<\/p>\n \u00a0<\/p>\n We must also not forget to protect the data to which a legitimate guest can have access to, which gives rise to several measures:<\/p>\n Moving a step further, a Cloud Access Security Broker<\/strong> (such as Microsoft’s MS Defender for Cloud Apps) can enable the implementation of advanced and targeted rules, such as preventing uploads to specific Sharepoint spaces as an example.<\/p>\n \u00a0<\/p>\n As mentioned earlier, the key topic is managing the lifecycle of “guest” identities<\/strong> i.e., the creation, deletion, and review of access. As such, there are 3 scenarios to be considered. These scenarios depend on the desired risk coverage<\/strong>, the level of maturity <\/strong>of identity and access management, and the cost of implementing<\/strong> the scenario.<\/p>\n Figure 5 – Guest Identity Lifecycle Management Scenarios<\/em><\/p>\n \u00a0<\/p>\n In this scenario, the company creates a certain group typology for \u201cExternal\u201d groups<\/strong>, and therefore to the creation of guests. The distinction can be made by the use of language by the group. For example: all external groups must start with “X_”.<\/p>\n It can thus carry out checks more easily on this limited perimeter of groups.<\/p>\n The main prerequisite is to block the addition of “guest” identities to \u201cInternal\u201d groups. <\/strong>This is possible in two ways:<\/p>\n The only way to create a “guest” identity is to add them as external users to “External” group types.<\/strong><\/p>\n If the company needs to give its tenant access to a subsidiary or an entire entity, it is possible to regularly synchronize their AD or Azure AD, and thus create their identities as a “guest” in the tenant of the company.<\/p>\n The process of deleting identities is simple through the deletion of inactive “guest” identities. <\/strong>For example, using a PowerShell script based on the frequency of “Sign-In Activity”. Alternatively, it is also possible to remove “guest” identities that do not have access to any group via a PowerShell script.<\/p>\n It is possible to expire access for “guest” identities<\/strong> on SharePoint groups or OneDrives after 60 days. Note that the owner of the SharePoint or OneDrive group will be notified of the expiration 21 days beforehand.<\/p>\n Figure 6 – Guest Access Expiration<\/em><\/p>\n \u00a0<\/p>\n Finally, it is possible to use the “Guest Access Review” feature for external groups. It should be noted, however, that this feature requires advanced licenses (AAD P2) assigned to the users who carry out the reviews i.e. all the owners of the groups (normally a small number).<\/p>\n This scenario is an efficient way that reduces guest risk, maintains a near-native solution, and doesn\u2019t require too much investment.<\/strong><\/p>\n \u00a0<\/strong><\/p>\n In this second scenario, the company wants to have complete control over the lifecycle management of “guest” identities<\/strong>. To do this, the company creates an application<\/strong> (for example by using Power App) to manage this lifecycle, making it the single point of creation and deletion.<\/p>\n Once this lifecycle is in place, it is necessary to set the SharePoint sharing setting to “Existing guest only” mode, allowing only content to be shared with “guest” identities that already exist in the Azure AD tenant. This prevents the creation of new identities through this vector.<\/p>\n Figure 7 – Restricting Sharing Opportunities<\/em><\/p>\n In this scenario, users use the dedicated application to create the “guest” identities<\/strong> by entering an end date. The user then designates the owner of the identity created.<\/p>\n To delete identities, it is possible to trigger an automatic workflow<\/strong> before the end date by asking the owner of the identity in question whether to delete it or extend its end date. It should be noted that if the owner has left the company without making the change of ownership, consideration can be given to reassigning the guest to his or her supervisor.<\/p>\n With this type of “in-house” application, it is complicated to go much further in the management of the lifecycle – especially when it comes to access review.<\/p>\n It is still possible, as in Scenario 1, to expire guest access or to use the “Guest Access review” feature (with the same constraints as stated above).<\/p>\n To go further, we can also consider the use of third-party tools such as IDECSI or Sharegate that make it possible to manage these access journals automatically and intuitively.<\/p>\n This scenario changes the native behavior and enables better control of the lifecycle, but at a significant blow with regard to the deployment and the management of the change to be implemented.<\/strong><\/p>\n The last scenario to consider is a variant of the previous scenario, where the company still wants to have control over the lifecycle management of “guest” identities. In this case, the company can integrate “guest” identity management into its identity and access management (IAM) tools<\/strong> in the same way as “external” identities.<\/p>\n The IAM tool then becomes the authoritarian source<\/strong> for this type of population and its management is done directly there.<\/p>\n In this scenario, as in the previous one, you must also set the SharePoint sharing setting to “Existing guest only” mode.<\/p>\n Identities are created on external creation forms<\/strong> from IAM tools by choosing the “guest” type for the identity. The “guest” identity can then be provisioned automatically in the Azure AD by IAM tools.<\/p>\n The removal of the identity is also done by the IAM tool<\/strong> according to the positioned end date and the workflows already defined.<\/p>\n In the event that the company’s IAM tools are used to manage rights on Sharepoint spaces, it is possible to use the access review capabilities of these tools<\/strong> to review access to sensitive resources for which “guest” identities have access.<\/p>\n Alternatively, a second option is to use access governance features via IAM solutions, such as Sailpoint OneIdentity, or via dedicated Identity and Access Governance solutions, such as Brainwave or Varonis. We can imagine retrieving the rights assigned directly in the Azure AD and having them verified to the owners of the resources through these tools.<\/p>\n This scenario is a variant of Scenario 2, which allows the most mature companies in identity and access management to capitalize on existing tools and processes.<\/strong><\/p>\n It is useful to build a form of adapted reporting using KPIs and dashboards<\/strong>. A pool of information is available natively in the Azure AD (date of last connection, activity on the tenant as well as on Office 365 via the “unified audit logs”). This information can be interacted with via visualization tools, like Power Bi, for the generation of dashboards.<\/p>\n Secondly, it is important to monitor the activities of these particularly exposed populations<\/strong>. Two levels of detection can be set up depending on monitoring capabilities:<\/p>\n We can imagine the use of the Azure AD Identity Protection<\/strong> module to trigger alerts for guests with a high level of risk.<\/p>\n \u00a0<\/p>\n AAD B2B greatly simplifies<\/strong> collaboration with users outside the company, but entails risks related to the default operation<\/strong> of the solution. To control these risks, it is necessary to reduce <\/strong>the level of open access, and to control the lifecycle of these identities<\/strong> at a deeper level, depending on the potential level of investment that is planned. Finally, it is necessary to focus on monitoring<\/strong> via native tools or tools used by the company given the high exposure of these populations.<\/p>\n \u00a0<\/p>\n","protected":false},"excerpt":{"rendered":" The use of “guest” identities to facilitate collaboration externally \u00a0 The need for collaboration externally entails risks for companies Companies have always needed to collaborate with each other by sharing resources and exchanging data. To do this, their collaborators must…<\/p>\n","protected":false},"author":1293,"featured_media":18352,"comment_status":"open","ping_status":"closed","sticky":true,"template":"page-templates\/tmpl-one.php","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3266,3977],"tags":[3359,3679,4098,2827,4099],"coauthors":[2864,4096,4097],"class_list":["post-18362","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-next-gen-it-security-en","category-focus","tag-azure-en","tag-azure-ad-en","tag-collaboration-2","tag-identity","tag-o365-2"],"acf":[],"yoast_head":"\n\n
\u00a0<\/h2>\n
Microsoft introduced Azure AD B2B to address the need for collaboration<\/h2>\n
\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2022\/08\/Image1.png\")
<\/em><\/p>\nHowever, Azure AD B2B has a default configuration that is too open, which creates risks for the company<\/h2>\n
\n
\n
\n
Depending on the level of maturity of the company and the willingness to hedge risk, it is necessary to implement a number of measures<\/h1>\n
\u00a0<\/h2>\n
To get started: harden the default configuration<\/h2>\n
\u00a0<\/h4>\n
Master the means to add “guest” identities on the tenant<\/h4>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2022\/08\/Screen1.png\")
<\/p>\n\u00a0<\/h4>\n
Restrict what these identities can access<\/h4>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2022\/08\/Screen3.png\")
<\/p>\nStrengthen authentication and access control of “guest” identities<\/h2>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2022\/08\/Screen2.png\")
<\/p>\n\n
Educate users about risks and best collaboration practices<\/h2>\n
\n
Protect the data that guests can access<\/h2>\n
\n
Managing the Lifecycle of Guest Identities: 3 Scenarios to Consider<\/h2>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2022\/08\/Image2.png\")
<\/p>\nScenario 1 – Stay pragmatic on a budget: use native tools and configurations<\/h3>\n
\n
Creating a “guest” identity<\/h4>\n
Deleting a “guest” identity<\/h4>\n
Review of “guest” access<\/h4>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2022\/07\/Picture7.png\")
<\/p>\nScenario 2 – To go further in the level of security: develop a guest management application<\/h3>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2022\/07\/Picture8.png\")
<\/p>\nCreating a “guest” identity<\/h4>\n
Deleting an “invite” identity<\/h4>\n
Review of “guest” access<\/h4>\n
Scenario 2′ – Integrating “guest” identities into traditional IAM processes<\/h3>\n
Creating a “guest” identity<\/h4>\n
Deleting a “guest” identity<\/h4>\n
Reviews of “guest” access<\/h4>\n
\u00a0<\/h2>\n
Finally, do not neglect the surveillance of this exposed population<\/h2>\n
\n
In conclusion, AAD B2B greatly facilitates collaboration, but its configuration needs to be hardened to reduce the level of risk induced by the solution<\/h1>\n