Cross-Tenant Access Settings Improvements!

By August 30, 2023AzureAD

[ad_1]

Hello friends,

 

Hard to believe it’s been almost a year since we made cross-tenant access settings generally available. Since then, it’s been awesome seeing you adopt this feature to secure your cross-tenant collaboration scenarios and improve end-user experiences for partners by setting up trust of multi-factor authentication (MFA) from their home tenants. With that said, we’ve also heard your feedback on a few critical areas.

 

We’ve been hard at work to address that feedback and we have some new improvements to share.

 

  1. You can create custom roles and use protected actions to secure changes in cross-tenant access settings.
  2. We’ve removed limits so you can set up policies for as many partners as you want.
  3. Invitations respect cross-tenant access settings protecting your tenant from unapproved users and preventing user confusion.

 

It’s great to see the team making continuous improvements, thank you for your feedback! Now I’d like to welcome back Senior Product Manager, Josh Douglas, to the blog to walk you through the details.

 

Robin Goldstein

Twitter: @RobinGo_MS

 

————————

 

Hi everyone, this is Josh.

 

I’m excited to share how cross-tenant access settings can better assist you on your zero-trust journey!

 

Let’s dive right into the changes:

 

Create custom roles and protect cross-tenant access settings administration

 

One of the things we hear a lot is that you want to create your own roles for managing cross-tenant access settings. Today, you need to use either a Global or Security admin to fully manage cross-tenant access settings. Now you can use custom roles to create roles that meet the requirements you have. We’ve seen customers create a full cross-tenant access administrator, a partner administrator, and even a cross-tenant access reader. This allows you to delegate only the rights needed to perform these management actions without granting too many permissions.

 

The cross-tenant access settings admin experience has also been updated to respect these new custom roles. If a user does not have the proper permissions, the experience will update and only allow them to perform the actions they have access to perform.

 

Figure 1: A read-only role cannot perform any edit actions.Figure 1: A read-only role cannot perform any edit actions.

 

Figure 2: A read-only role can view settings but is informed they are in a read-only view.Figure 2: A read-only role can view settings but is informed they are in a read-only view.

 

Learn more about custom roles in cross-tenant access settings.

 

In addition to supporting custom roles, cross-tenant access settings permissions have also been onboarded as protected actions. This allows you to protect management actions with Conditional Access policies. For example, to change default settings for B2B collaboration first requires that you perform MFA.

 

Figure 3: A conditional access policy for protected actions requires MFA before making updates to default settings.Figure 3: A conditional access policy for protected actions requires MFA before making updates to default settings.

 

We believe with these new capabilities it will empower you on your journey to zero-trust to give admins only the permissions they need to perform management of cross-tenant access settings and keep those highly privileged actions protected with Conditional Access policies!

 

Learn more about protected actions.

 

No more limits on number of partners in cross-tenant access settings

 

We’ve heard from many of you that you have needs to collaborate with hundreds, or even thousands, of organizations and you needed a way to manage all those relationships. Cross-tenant access settings originally had limitations and we realized that those limitations stood in the way of enabling you to manage all of your partnerships.

 

To solve this problem, we’ve created a new way of storing data for partners in cross-tenant access settings, where each partner has their own partner policy. With this new model, you can add as many partners as required. From your standpoint, nothing will change with how you manage cross-tenant access settings. You’ll still manage things exactly the same way via the Entra portal or Microsoft Graph, but you’ll no longer hit any size limitation when adding new partners in cross-tenant access settings.

 

We are beginning to migrate all customers who use cross-tenant access settings to this new, scalable model in CY23 Q3. You may notice an audit log entry for our service that conducts the migration once your tenant is migrated, but there is nothing to worry about! This is our service just moving your configuration to the scalable model, unlocking this new capability for adding as many partners as you need!

 

Invitations respect cross-tenant access settings

 

Until now, even if you had blocked someone in cross-tenant access settings, or only allowed specific partners, you could still send B2B invitations to any of the users who may be blocked. After receiving the invitation, they would be blocked as they tried to redeem the invite and access resources. This is a confusing experience for both the inviter and invitee, as the invite went through and then the user was blocked.

 

We’ve introduced a change to make this a better experience all around. We now respect your cross-tenant access settings when sending B2B invitations. This means that for any organization you have blocked, you will no longer successfully invite those users and we will instead fail the invitation and make it clear you need to update cross-tenant access settings if you’d like this invite to go through.

 

Learn more about using cross-tenant access settings to restrict B2B invitations.

 

We hope you’re excited about these improvements in cross-tenant access settings and can leverage them to work towards a zero-trust posture. As always, let us know if you have any feedback by reaching out to us through the Azure forum or tagging @AzureAd on Twitter!

 

Josh

Twitter: @joshkdouglas

 

 

Learn more about Microsoft identity:



[ad_2]
Source link

Share this post via

Leave a Reply