Azure AD B2B: Security considerations to protect external (privileged) identities

In the recent months I‘ve spent time on research of identity security in B2B scenarios (when users are invited to another Azure AD tenant). In this blog post I like to share a few insights about known but also undocumented limitations or concerns of identity protection in Azure AD B2B. All results of my research were double checked in my lab environments, but I would be very interested to hear feedback from others about their experiences or technical insights.

Note: The following security concerns were submitted to „Microsoft Security Response Center“ (MSRC) during a case in June and July 2020. I‘ve shared details of my research work and potential attack scenarios. In the end the MSRC gave me the following feedback:

„Upon investigation, we have determined that this submission does not meet the bar for security servicing. This report does not appear to identify a weakness in a Microsoft product or service that would enable an attacker to compromise the integrity, availability, or confidentiality of a Microsoft offering.“

Use cases of invited users (outside of the resource tenant)

Before we go into details … I like to list some use cases where users will be invited to other Azure AD tenants as part of the Azure AD B2B feature:

• Business-to-Business (B2B) collaboration or partnership to other organizations:
  I guess this is the most familiar example and many aspects of Azure AD B2B are originally designed for this scenario. One organization invites member (work accounts) from a partner organization to the Azure AD tenant for sharing infrastructure or access to project/business resources. This may be the case, if guest users needs access to shared files (OneDrive) or different project teams have to collaborate closely (Microsoft Teams).
• External administrators to manage your Azure AD or Azure resources:
  External users will be invited to Azure AD tenant for delegation of administrative or privileged tasks. Azure Security Center (ASC) shows as recommendation to remove external identities from Azure (subscription) RBAC roles. From my point of view there are some cons and pros around the dependency of identity (lifecycle) from an external organization. However, you should verify (on your conditions) if it‘s an prefer (secure) option to use a full-managed privileged identity from your directory.
• Administration of Azure AD B2C tenant from Azure AD Premium (B2E) tenant:
  As you may already know, Azure AD B2C tenants are not supporting premium protection features (licensed as “Azure AD for O365” tenant only) yet. Conditional Access and Identity Protection for B2C was already announced at Ignite 2019. Today it might be a good practice to use privileged identities from Azure AD (B2E) Premium tenant. The option to invite guest users to B2C tenant for administration is also described by Microsoft. Basically external users from a Azure AD Premium tenant can be assigned to Conditional Access and Identity Protection risk-based policies/reports in the home tenant.
• Centralized Azure AD „Management“ tenant to manage a multi-tenant (enterprise) environment:
  I‘ve heard a few times that some (large) organizations implemented an internal „management“ tenant in the past. All privileged identities and resources will be located in this directory to use „shared services“ across a multi-tenant environment. In the recent year(s) many enhancements were introduced to separate or isolate resources within one tenant (e.g. Administrative Units, Custom Roles, fine-grained policies etc.). Using one tenant per organization was also strongly recommended by Microsoft but from historical or technical reasons (company merge, geo-political, technical limitations) real-world practice shows some (valid) alternate approaches.

In this diagram you can see the environment and “wordings” that I will use for further explanation about the B2B scenarios and examples of my security considerations:

Limitations or considerations that could allow „bypassing“ of your identity protection mechanism in B2B scenarios

The follow findings can be reproduced as far your accessing resources by the TenantID parameter of the inviting tenant (such as PowerShell, Az CLI or Portal URL).

Portal URLs:

https://portal.azure.com/<TenantIDOfInvitingTenant>
https://aad.portal.azure.com/<TenantIDOfInvitingTenant>

PowerShell:

$Credential = Get-Credential
$TenantID = <TenantIDOfInvitingTenant>
Connect-AzureAD
       -Credential $Credential
       -TenantId $TenantID

Note: All of the following research results and instructions was performed or tested in July 2020. Since then, Microsoft may have changed functionality or features around the described scenario.

No sign-in failure events if sign-in attempts of invited users in inviting tenant has failed

Description:

Sign-in failures of invited users will not be audited (neither in invited nor inviting tenant). This only applies to authentication scenarios where Azure AD will be used for primary credential validation (Password Hash Sync). ADFS- or PTA-Authentication allows you to see the failed validation attempts to your Active Directory (On-Premises) infrastructure. As far as I know, this limitation is not documented by Microsoft.

Potential risk or security concern:

Any kind of sign-in failures (including “Password Spray” or “Brute force” attacks) from an inviting tenant are not visible for SecOps.

Currently there are no options to restrict “inbound” invitations (list of domains that are allowed to invite users of your tenant). Only inviting domains of “outbound” invitation can be limited. In combination with the missing sign-in failure events it may lead to the concern that you have limited control and visibility of invited users by external partners (B2B).

Note: Erlend Andreas Gjære (SecurePractice.co) describes a sample of attack scenarios where Azure AD B2B invitations can be used for phishing attacks. The inviting user will be forwarded to “MyApps” portal which includes a published app with attacker’s own login page to phishing (entered) credentials.

Technical Background and Reproducing:

1. Search for the Tenant ID of the inviting tenant: Anonymous (e.g. OpenID Discovery (wellknown) or online tools such as “WhatIsMyTenantID.com”) or as authenticated user via PowerShell
2. Navigate to a resource of the inviting tenant: https://portal.azure.com/”TenantIDOfInvitingTenant”
3. Enter the name of the invited user or try to enumerate a user name that could be invited. Note: David Chronlund has written a great blog post with some insights on “Automatic Azure AD User Account Enumeration with PowerShell “

4. Enter (various) wrong credentials to generate failed sign-in attempts until account is temporarily locked (by default a lockout threshold of 10 attempts is configured). You will see the following message, which shows that Smart Lockout was triggered:

   

   Note: Smart Lockout of the home tenant will applied to invited users which can be verified by changing the lockout threshold to any non-default value.

5. Check if sign-in failures are visible in the Azure AD Sign-in logs and MCAS activity (Azure App Connector/Azure AD events). In my tests this was not the case:

   

6. Optional: Check the MCAS activity logs if you have connected your Azure ATP instance and using PTA or ADFS as primary authentication. You’ll find a failed logon event as part of Azure AD authentication request. In my sample the „Authentication Agent“ of PTA is located on server “DS1”. This is the internal credential validation between “PTA Agent” and domain controller but not the original request.

   

Mitigation or workaround:

Migration to Pass-trough Authentication (PTA) as primary authentication method is technically an option but may also lead to several other disadvantages (depending on your availability and environment requirements). Especially if we talk about privileged identities which I recommended to create as cloud-only identities.

Azure AD Smart Lockout will throttle the attempts and risks of „Password Spray“ or „Brute Force“ attacks to invited users even if you have no visibility to this events. In my opinion there’s no option to increase the visibility of sign-in attempts for the invited organization yet.

It should be recommend to implement a security process and monitoring for B2B invitation of your users to other tenants. Unfortunately the tenantID of the inviting tenant seems not be included in the sign-in logs to the “Microsoft Invitation Acceptance Portal”. So it’s hard to detect the tenantID of the inviting tenant on a early stage in the invited tenant. Invitation process (incl. who has invited the user) can be audited in the inviting tenant very easily (included in “Audit” and “Sign-in”-logs).

Note: Have a look on the “Tenant restrictions” feature if you want to define a list of tenants that are permitted to access (requires proxy HTTP header insertion and TLS interception).

Conditional Access Policy from home tenant will not be applied

Description:

Microsoft has already acknowledged the fact that Conditional Access Policies from the home tenant will be not enforced (such as MFA requests):

“The inviting tenancy is always responsible for MFA for users from the partner organization, even if the partner organization has MFA capabilities”.

Source: Microsoft Docs (“Conditional Access for B2B collaboration users”)

Therefore it’s important to know that policies from the home tenant will not be applied when a inviting user accessing resources of the inventing tenant directly (by using the TenantID parameter).

Details on “bypassing” Conditional Access Policies from the home tenant as invited users was already described in a great blog post by Stephan Waelde. He has also figured out that invited users are able to read basic information of all applied and non-applied policies in the inviting tenant (MySignIn reports).

Potential risk or security concern

• No option to protect or restrict access of (Azure AD) work accounts by Conditional Access (CA) Policies across company / tenant boundaries:
  • Example of user-based policy: Invited users may not requested for MFA registration and strong authentication in the resource tenant. Some organizations excluded B2B users to avoid “double MFA” and additional management of MFA methods. Recommendation to require MFA for B2B users in the inviting tenant (if strong authentication is required) could be overlooked in misunderstanding of responsibility to enforce MFA.
  • Example of device-based policy: Invited users are able to access resources in inviting tenant from non-compliant devices. Inviting organizations may excluding B2B users from device-based policies because they’re not managed and can’t be compliant with the device policies of the resource tenant.
• Additional administrative efforts (and higher risk of misconfiguration) to enforce CA strategy across all tenants (in case of a multi-tenant-environment) within an organization.

Technical Background and reproducing:

1. Create various “Conditional Access Policies” in the home tenant that will apply to the test user. Check sign-in activities from the user in the home tenant to get an overview of all policies that were applied:

   

   Optional: Check “What if” to simulate conditions and control of enabled CA policies

   

2. Try to access resources of the inviting tenant from your invited user (and a non-compliant / unmanaged device like in this sample). Don’t forget to use the TenantID parameter! Afterwards check the sign-in logs in home and resource tenant for applied policies:

   

   

   As you can see only Conditional Access policies from the inviting tenant was applied to the invited user. In this case the user has access to the resource tenant without any device- or MFA requirements (as defined in the home tenant).

Mitigation or workaround:

Multi-Tenant Environment

Ensure that required “Conditional Access Policies” are also deployed and assigned in resource tenants. Misconfiguration and administrative efforts/costs can be reduced by automated deployment (to your multi-tenant-environment). Alexander Filipin has started a GitHub project to provide a fully automated solution for achieving an “As Code” approach for Conditional Access. Strongly recommended to have a look on his policy set and automation!

Delegated Privileged Access to Azure AD B2C or other Azure AD “Free” Tenants

All new created tenants (starting from October 2019) will be protected by a minimum set of policies (“Security Defaults”). This is not the case for B2C tenants because it seems not to be supported for this kind of directories. New B2C tenants will be created without security defaults. Previous “Baseline policies” are deprecated and can’t be enabled anymore. The announced support of Conditional Access and Identity Protection for Azure AD B2C will resolve this security concern finally.

Enabling of “Security defaults” for all other (free) Azure AD tenants is supported and will enforce MFA for administrators in the tenant which also covers invited privileged users. But you will have no option to exclude “emergency access accounts” (aka “break glass” accounts). This also prevents you to configure other condition/controls as part of Conditional Access Policies (registered device required for privileged access). It’s necessary to use custom “Conditional Access” as far it’s technically possible.

Monitoring access to inviting tenant from privileged users without MFA

I’ve tried to write a simple Azure Sentinel / KQL query to detect sign-ins without MFA from (invited) privileged users. In many cases the sign-in logs of the inviting tenant shows that MFA requirement was satisfied by a claim in the token even if it wasn’t required. The query can be used in the inviting tenant and filtered users by name prefix of your privileged accounts. This is still an experimental query without any warranty. You’ll find the latest version in my GitHub repository: azuresentinel/SignInFromExternalPrivilegedUserWithoutMFAClaim.yaml

No enforcement of sign-in risk and user risk policy in inviting Azure AD tenants (without Identity Protection)

Description:

Every inviting tenant without configured sign-in or user-risk policy will not responding to the evaluated risk from the invited tenant. This was the result of my research which seems to be also covered by Microsoft’s statement:

The user risk for B2B collaboration users is evaluated at their home directory. The real-time sign-in risk for these users is evaluated at the resource directory when they try to access the resource.

Source and detailed information: Microsoft Docs (“Identity Protection and B2B users”) 

In addition Microsoft also consider the following limitation as part of the Identity Protection documentation:

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.

Source: Microsoft Docs (“Risk-based Conditional Access for B2B”)

Potential risk and security concerns:

• Users with risky state in home tenant are able to accept invitation from inviting tenants.
• Azure AD tenants without sign-in risk or user risk policy for guests: Users are able to access resources in the inviting tenants even if they are flagged as risky users in the invited tenant or sign-in risk to inviting tenant was detected.

Technical Background and Reproducing:

1. Create a user account in home tenant with assigned Azure AD Premium license and risk-based policies (user and sign-in risk policy in Identity Protection). Control of sign-in risk policy should be set on risk-level “Medium and above” to require “multi-factor authentication”. User Risk policy should be configured to require “Password change” by user risk level “high”.

   Note: Be aware of latency of some detections and algorithm requirements (e.g. 14 days / 10 logins for atypical travel). Check out the “Simulate risk detection” documentation by Microsoft for more details.

2. Invite the user from Azure AD Tenant without configured (Identity Protection) risk-based policies. Note: In one of my tests I’ve used an account which was already flagged as risky (in the home tenant) before invitation was redeemed and sign-in successfully:

   

   

3. Try to sign-in from an Tor browser by accessing the Azure Portal with TenantID parameter (https://portal.azure.com/) as already described. Access from an anonymous IP address is one of the real-time detections that could be used to trigger a sign-in risk policy.

   In my tests, the invitied user was not be prompted for MFA (sign-in risk response) which underlines the statement that sign-in risk is evaluate in the resource tenant (as we can see it is not the case if it’s not available).

   Note: Sign-in process stopped by forwarding from login.microsoftonline.com to portal.azure.com (“Keep me sign in” prompt) in some test scenarios. If this happens try another portal that is supporting TenantID parameter such as Azure AD portal (aad.portal.azure.com) or Azure AD Preview portal (preview.portal.azure.com).

4. Check the identity risk detection in the home/invited tenant after few minutes. Real-time risk (anonymous IP address) was detected by Identity Protection:

   

5. The following screenshot shows the original sign-in event that is audited in the home and resource tenant:

   

   

6. Navigate to a resource of the home tenant ([https://portal.azure.com/](https://portal.azure.com/)) in the Tor Browser to verify that user risk detection will be triggered if risk-based policies are enabled:

   

7. Optional: Invite your test user to any other tenant with enabled Identity Protection and assigned user risk and sign-in risk policies to all users (including guest). The risk-based policies will be triggered in real-time and works as expected (e.g. access from risky users will be blocked).

Mitigation or workaround:

Blocked sign-in (disabled user) or forced password change of sensitive or privileged Azure AD accounts that are flagged as risky, could be a replacement for automated response. Azure Sentinel playbooks can be used to run automation with additional security operations such as revoke user‘s refresh token or reset user password.

Note: Consider the lifetime and behaviour of various type of tokens if you need to revoke access. Microsoft publish a new article which includes a general overview on revocation of user access in Azure AD.

Detection of risky and “non-applied policies” sign-ins to Azure Portal seems to be possible. I’ve used the following query to detect sign-ins with risk detection and non-applied “Conditional Access policies” from the home tenant during my tests. This query is simple but also very experimental. Feel free to use it (without any warranty)! The latest version of this query is available from my GitHub repo: azuresentinel/RiskySignInToAzurePortal.yaml

Enabling sign-in and user risk policy in the inviting / resource tenant (if possible) should be the best mitigation. This will also enforce risk-based policies to your other company tenants. Consider that remediation of user risk must be performed in the home tenant and access could be blocked to resource tenant.

Side note: Offline detection and sign-in risks

I’ve tested also various offline detections such as „Atypical travel“ or “Malicious IP address” during my research. Therefore I created two accounts (GuestUser and GuestAdmin) and invite them to a Azure AD Premium and Azure AD B2C tenant. I’ve used various public proxy servers to simulate the sign-ins from geographically (far) distant locations . It’s good to know that sign-ins with offline calculated risks will be also detected and reported in the home tenant.

But keep in mind to monitor them explicit and build an automation to response this identity risk if the resource tenant hasn’t any risk-based policy for auto-response.

Original cover image by mohamed Hassan / Pixabay