Microsoft Entra External ID: B2B, Guest Access, and Cross-Tenant Setup
Why This Is Happening
I've seen this exact confusion play out on hundreds of enterprise helpdesk tickets , an admin tries to invite a partner to collaborate on a SharePoint site, the guest email bounces back with AADSTS65001, or the invitation lands but the guest hits a blank error page when they click "Accept." Sound familiar? I know it's frustrating, especially when it blocks a real deadline.
Here's the core problem: Microsoft Entra External ID is actually two separate products living under one brand name, and most admins don't realize that until they're already deep in the wrong settings panel. There's the workforce tenant path , which is what you use for B2B collaboration with external partners, vendors, and guests, and then there's the external tenant path, which is a completely different configuration built for consumer app developers who need customer identity and access management (CIAM). Microsoft calls this distinction "workforce configuration" versus "external configuration," and mixing them up is the single biggest source of setup failures I encounter.
On top of that, Microsoft rebranded Azure Active Directory to Microsoft Entra ID in 2023, and the old "External Identities" menu in the Azure portal got folded into the new Entra admin center. If you've got bookmarked links to portal.azure.com/#blade/Microsoft_AAD_IAM/..., some of those deep links now 404 or redirect incorrectly. Your institutional memory from the Azure AD B2B days still mostly applies, the underlying concepts haven't changed, but the navigation paths have moved around enough to cause real pain.
Then there are cross-tenant access settings. These were introduced relatively recently and they control, at a very granular level, what external users from other Microsoft Entra tenants can and can't do in your environment. A lot of organizations have never touched these settings, which means they're sitting on Microsoft's defaults, and those defaults sometimes block specific collaboration scenarios that you'd expect to just work.
The error codes you'll see most often in this space are AADSTS65001 (consent not granted for the application), AADSTS50020 (the user account does not exist in the tenant), AADSTS7000218 (the request body must contain a client_secret), and AADSTS900144 (the request body must contain a parameter). None of those error messages actually tell you what to do. That's what this guide is for.
Whether you're an IT admin trying to get a consultant into your Microsoft 365 environment, a developer building a consumer sign-up flow, or someone who just inherited a messy Entra setup, you're in the right place. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your immediate problem is "I sent a guest invitation and it's not working," here's the fastest path to a fix. Nine times out of ten, the culprit is either guest invite permissions being restricted to admins only, or cross-tenant access settings blocking inbound B2B collaboration from the guest's home tenant.
Start here: open the Microsoft Entra admin center at entra.microsoft.com and sign in as a Global Administrator or an External Identity Provider Administrator. In the left sidebar, go to External Identities → External collaboration settings.
Under "Guest invite settings," check what's selected. If it says "Only users assigned to specific admin roles can invite guest users", and you're not one of those admins, that's your problem. Change it to "Member users and users assigned to specific admin roles can invite guest users" or broader, depending on your organization's policy. Click Save.
Next, still in External Identities, go to Cross-tenant access settings. Click the Default settings tab. Under "Inbound access settings," make sure B2B collaboration is not set to block all external users. The default should allow B2B inbound, but if someone has tightened this previously, it will silently block all incoming invitations regardless of what you do elsewhere.
If the invitation was already sent before you made these changes, you'll need to resend it, existing invitation links don't retroactively become valid. Go to Users → All users, find the pending guest (their account type shows as "Guest"), click their name, and under the Overview tab you'll see a "Resend invitation" option. Click that and send a fresh link to the guest's email.
In most cases, these two changes, guest invite settings and cross-tenant default inbound policy, resolve the issue immediately. If the guest still can't get in after a fresh invitation, move on to the step-by-step section below.
AADSTS50020 or AADSTS65001, tells you exactly which layer is failing, which cuts diagnosis time from 30 minutes to about 2.
Cross-tenant access settings are the master control panel for how your tenant interacts with other Microsoft Entra tenants, and they're separate from the old "External collaboration settings" panel that most admins already know. Think of them as a firewall specifically for Entra-to-Entra traffic.
In the Entra admin center, navigate to External Identities → Cross-tenant access settings. You'll see two tabs: Default settings and Organizational settings.
Default settings apply to every external tenant you haven't explicitly configured. Click "Edit inbound defaults" and you'll see controls for B2B collaboration (can external users be invited at all?) and B2B direct connect (a separate feature for shared Teams channels). Make sure "Allow access" is selected for B2B collaboration under the inbound tab. Repeat for outbound if your users need to access resources in partner tenants.
Organizational settings let you create trust relationships with specific tenants, for example, you can tell your Entra tenant to trust MFA claims from a specific partner organization, so their users don't get double-prompted for MFA when they access your resources. Click "Add organization" and enter the partner tenant's domain or tenant ID. From there you can customize inbound and outbound access specifically for that org, much tighter control than the defaults.
After saving, allow about 5 minutes for the settings to propagate before testing. If you're in a rush, you can force a policy refresh by signing out and back in on the guest-side test account. When it works, the guest should land on your tenant's sign-in page without hitting any "You don't have permission to access this" wall.
B2B collaboration in Microsoft Entra External ID works through an invitation model, you add an external user to your directory as a guest, they get an email with a redemption link, and after they accept, their external account gets a shadow representation in your tenant. Here's how to do it correctly.
In the Entra admin center, go to Identity → Users → All users. Click "New user" at the top, then choose "Invite external user." Fill in the guest's email address, this should be their actual work or personal email, not an alias. The display name is pre-populated from the email but you can override it.
In the "Personal message" field, add a note explaining why you're inviting them. This isn't just politeness, guests are increasingly cautious about unexpected invitation emails due to phishing. A recognizable message dramatically increases acceptance rates.
Under Properties, you can assign a department, job title, and usage location. The usage location matters if you plan to assign Microsoft 365 licenses to this guest later, it must match the geographic region of the licenses you're assigning.
Click Invite. The guest now exists in your directory with an "Invitation pending" status. You can assign them to groups, apps, and roles before they've even accepted, which is useful for pre-provisioning access so they can get to work the moment they click Accept.
If the guest's home organization uses a different identity provider (like Google Workspace), Microsoft Entra handles the federation automatically. The guest will sign in with their Google account and your tenant recognizes them via the email-based identity mapping.
This is where most support tickets actually originate. The guest receives the invitation, clicks the link, and something goes wrong. Here's what the process looks like from their side, and where it breaks.
The guest gets an email from invites@microsoft.com with a subject line like "You've been invited to [Your Organization Name]." They click "Accept invitation." This opens a browser and takes them to myapps.microsoft.com with a redemption URL containing a one-time token.
If the guest already has a Microsoft account (personal or work), they'll be prompted to sign in. If they don't, they can create one or use a one-time passcode (OTP) sent to their email, Microsoft Entra External ID supports OTP redemption as a fallback identity method, which means guests without any Microsoft account can still collaborate.
Common failure points:
- AADSTS50020: The guest signed in with a different email than the one you invited. They need to sign in with the exact address the invitation was sent to.
- AADSTS65001: The app they're trying to access hasn't been granted consent for guest users. You'll need to pre-consent the app for external users in your tenant's app registrations, or enable admin consent for the application.
- "This invitation has expired": Invitation redemption links expire after 30 days by default. You can resend from the user's profile page in the Entra admin center as described in the Quick Fix section above.
If the guest is on a managed device in their own organization, their IT policies might intercept the redemption URL. In that case, they should try accepting from a personal browser profile or an unmanaged device to isolate whether the problem is on their end or yours.
If you're building a consumer app, say, a customer portal, a SaaS product, or any public-facing application, you don't want to manually invite every user. That's where Microsoft Entra External ID's CIAM capabilities come in. You set up a user flow that defines exactly how customers sign up and sign in, then attach your app to that flow.
First, you need an external tenant, a separate Microsoft Entra tenant configured specifically for customer-facing scenarios, isolated from your workforce tenant. If you haven't created one yet, in the Entra admin center click "Create a tenant" and choose "External" configuration. Give it a subdomain under .onmicrosoft.com, for example, myapp.onmicrosoft.com. This takes a few minutes to provision.
Once you're working inside your external tenant, go to External Identities → User flows. Click "New user flow." Give it a name, I usually use something like SignUpSignIn_Customers so it's obvious what it does.
Under Identity providers, choose the sign-in methods your customers will have. Your options include:
- Email with password, classic username/password signup
- Email one-time passcode, passwordless, great for reducing friction
- Google, social sign-in (requires setting up a Google OAuth app first)
- Facebook, social sign-in (requires a Facebook app registration)
Under User attributes, select what information you want to collect during signup, display name, given name, surname, city, country, or custom attributes you've defined. Be deliberate here: every field you add is friction. Only collect what you actually need. Click Create when you're done.
A user flow on its own doesn't do anything, it needs to be attached to one or more apps. Here's how to register your application in the external tenant and wire everything together.
In your external tenant's Entra admin center, go to Applications → App registrations → New registration. Name your app, choose the supported account type (for a consumer app, select "Accounts in this organizational directory only" since this is your isolated external tenant), and enter your redirect URI. For a web app, this is typically something like https://yourapp.com/auth/callback. For local dev, http://localhost:3000/auth/callback works fine.
After creating the registration, note the Application (client) ID and Directory (tenant) ID from the Overview page, you'll need both in your app's authentication configuration.
Now go back to External Identities → User flows and click your user flow. In the left panel, click "Applications" and then "Add application." Select the app you just registered. This association is what tells Microsoft Entra which sign-in experience to show when a user hits your app's login page.
To test the whole flow end-to-end, click "Run user flow" from the user flow's Overview page. A test URL generates, open it in a private browser window. You should see your branded sign-up page with the identity providers you configured. Go through a test signup with a real email address you control. If you hit an error code, check the browser URL for an error_description parameter, it's usually more informative than the page itself.
To add custom branding, your logo, background image, and colors, go to User experiences → Company branding in the external tenant. You can upload a banner logo (max 36px height, displayed on sign-in pages), a background image, and configure accent colors that apply across all user flows in the tenant.
Advanced Troubleshooting
When the standard fixes don't resolve the issue, it's time to go deeper. Here's what I check in enterprise and domain-joined environments.
Using PowerShell to Manage External ID Settings
The Microsoft Entra PowerShell module (not the old AzureAD module, that one is deprecated) gives you scripted access to everything in the Entra admin center. Install it with:
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Policy.ReadWrite.CrossTenantAccess","User.ReadWrite.All"To list all guest users in your tenant and their invitation status:
Get-MgUser -Filter "userType eq 'Guest'" | Select-Object DisplayName, Mail, ExternalUserStateTo bulk-invite guests from a CSV file (a lifesaver for large partner onboardings):
Import-Csv "guests.csv" | ForEach-Object {
New-MgInvitation -InvitedUserEmailAddress $_.Email `
-InviteRedirectUrl "https://myapps.microsoft.com" `
-SendInvitationMessage:$true
}Your CSV just needs a column called Email. Run this as a Global Admin or User Administrator.
Reading the Sign-In Logs for Specific Error Codes
In the Entra admin center, go to Monitoring & health → Sign-in logs. Filter by date and by "User type: Guest." For each failed sign-in, the Basic info tab shows the error code and a failure reason in plain language. The Authentication details tab shows you which authentication methods were attempted and which step failed, invaluable for diagnosing MFA-related blocks.
Common enterprise-specific codes:
AADSTS900432: Cross-tenant access policy is blocking the request, check organizational-level cross-tenant settings for that specific partner tenantAADSTS53003: Access was blocked by Conditional Access policy, your CA policies may explicitly exclude guest users from accessing certain appsAADSTS500133: The assertion is not within its valid time range, a clock skew issue on the guest's device; they need to sync their system time
Conditional Access and Guest Users
One extremely common enterprise scenario: your IT team has tightened Conditional Access policies and those policies apply to guests but weren't designed with guests in mind. Check Protection → Conditional Access → Policies and look for any policy that includes "All users" in scope. Open each one and check whether guests (external users) are explicitly excluded. If they're included in a policy that requires a compliant device, guests who are on personal devices will be blocked every time, unless you add an exclusion for guest user types or scope the policy to internal users only.
B2B Direct Connect vs B2B Collaboration, Don't Mix Them Up
B2B direct connect is a separate feature from B2B collaboration that's specifically designed for shared Teams channels. If your organization is trying to set up a shared Teams channel with an external organization and it's not working, you need to enable B2B direct connect in cross-tenant access settings, not the regular B2B collaboration settings. These are configured in the same Cross-tenant access settings panel but under a different toggle.
If you're seeing AADSTS700016 (application not found in directory) or AADSTS7000215 (invalid client secret) and you've verified your app registration settings are correct, there may be a tenant-level configuration corruption that requires Microsoft to look at the backend. Similarly, if cross-tenant access settings are reverting to defaults after you save them, that's a replication issue on Microsoft's end. In either case, open a support case at Microsoft Support and include your tenant ID, the affected application (client) ID, and the exact error codes from your sign-in logs. The more specific you are, the faster they move.
Prevention & Best Practices
Once you've fought through an External ID configuration issue, the last thing you want is to hit the same wall six months from now. Here's how to set things up so you don't.
Document your tenant architecture before you build. The workforce/external tenant split is easy to mess up if you're under deadline pressure. Before you touch any settings, write down which tenant is for employees (workforce) and which is for customers or external-facing apps (external). Keep this in a shared wiki. I've seen teams accidentally invite consumer users into their workforce tenant and spend days unwinding it.
Use named locations in Conditional Access for guest policies. Rather than writing broad CA policies that include all users and then carving out exceptions, create a dedicated CA policy just for guest users. Assign it the minimum access controls that your security team requires for external parties, typically MFA on every sign-in, since you can't guarantee the guest's device compliance. This keeps your internal user policies clean and your guest policies deliberate.
Audit guest accounts quarterly. Guest accounts don't expire automatically, a vendor you invited in 2022 for a six-week project is still sitting in your directory right now unless someone removed them. Use this PowerShell snippet to pull a list of guests who haven't signed in within 90 days:
$cutoff = (Get-Date).AddDays(-90)
Get-MgUser -Filter "userType eq 'Guest'" -Property DisplayName,Mail,SignInActivity |
Where-Object { $_.SignInActivity.LastSignInDateTime -lt $cutoff } |
Select-Object DisplayName, Mail, @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}}Pre-test your user flows before launch. The "Run user flow" button in the Entra admin center generates a real test URL. Click it in a private browser with a disposable email account before any production traffic hits your consumer sign-up flow. Test every identity provider you've enabled, a Google social login that works fine in Chrome might break in Safari due to third-party cookie restrictions, and that's better to find out in testing than from an angry customer tweet.
Monitor the sign-in logs on an ongoing basis. Set up a Log Analytics workspace and route your Entra sign-in logs to it. Create an alert rule for external user sign-in failures above a threshold, say, more than 10 failures from a single guest account in one hour. That pattern can indicate either a configuration problem or an account compromise attempt.
- Enable email one-time passcodes as a fallback identity provider, it means no guest ever gets completely locked out just because their organization doesn't federate with Microsoft Entra
- Assign a Guest Inviter role to your helpdesk team instead of giving them Global Admin, least privilege for external user management, same practical capability
- In your external (CIAM) tenant, set up custom attributes before launch, adding new required attributes to a live user flow forces existing users through an attribute collection step they weren't expecting, which kills conversion rates
- Configure the "Terms of use" policy on your sign-up user flow before you have real users, retrofitting it later requires all existing users to re-accept on their next sign-in
Frequently Asked Questions
What exactly is B2B collaboration in Microsoft Entra External ID and how is it different from regular user accounts?
B2B collaboration lets people outside your organization, partners, vendors, contractors, access your apps and resources using their own existing identities, whether that's a Microsoft Entra account, a Google account, or a personal Microsoft account. They show up in your directory as "Guest" users rather than "Member" users, which means they get a constrained set of default permissions: they can see what they've been explicitly granted access to, but they can't enumerate your directory, see other users' profiles, or access resources they haven't been invited to. The key difference from a regular account is that you're not managing their credentials, their home organization (or identity provider) handles authentication, and your tenant just handles authorization.
What are cross-tenant access settings and do I actually need to configure them?
Cross-tenant access settings control the traffic between your Microsoft Entra tenant and other organizations' Entra tenants. They're split into inbound settings (what external users from other tenants can do in yours) and outbound settings (what your users can do in other tenants). The defaults are reasonably open, B2B collaboration is allowed in both directions, but you may need to configure these explicitly if your security requirements are strict, if you want to trust MFA or device compliance claims from a specific partner tenant, or if a partner organization has locked down their outbound settings. If you've never touched them and B2B collaboration is working fine, you probably don't need to. But if you're seeing AADSTS900432 errors, cross-tenant access settings are the first place to look.
How do I invite a guest user and what does the process look like from their end?
In the Entra admin center, go to Identity → Users → All users → New user → Invite external user. Enter their email, add a personal message, and click Invite. The guest receives an email from invites@microsoft.com and clicks "Accept invitation," which takes them to a browser-based consent and sign-in flow. They sign in with whatever account matches the email you invited, review what they're consenting to, and land in your tenant's My Apps portal. The whole process takes under two minutes for a guest who already has a Microsoft account, and maybe five minutes if they're setting up OTP-based access for the first time.
What is an external tenant in Microsoft Entra External ID and when do I need one?
An external tenant is a separately provisioned Microsoft Entra tenant in "external configuration", meaning it's designed specifically for managing customer-facing app users, not your employees. You need one if you're building a consumer or business-customer-facing app where end users sign up themselves, as opposed to being invited by an admin. The external tenant is completely isolated from your workforce tenant: users created there don't appear in your main directory, and the branding, sign-up flows, and identity provider settings are configured independently. If you're just adding partners and vendors to collaborate on internal tools, you don't need an external tenant, B2B collaboration in your existing workforce tenant is the right fit.
How do I create a user flow for customer sign-up in Microsoft Entra External ID?
Inside your external tenant, navigate to External Identities → User flows → New user flow. Give it a descriptive name, select your identity providers (email+password, OTP, Google, or Facebook), choose which user attributes to collect, and click Create. Once the flow exists, go to its Applications section and link it to your registered app. The flow defines the full sign-up and sign-in experience, what pages users see, what they fill out, and how they authenticate. You can run a live test directly from the admin center using the "Run user flow" button before connecting it to your production app.
What are the different user types in Microsoft Entra External ID and what permissions does each get?
The two main user types you'll work with are Member and Guest. Members are typically your internal employees, they have full directory read access by default and can see other users, groups, and some organizational settings. Guests are external users added via B2B collaboration, they have restricted directory access by default, can't enumerate users they haven't specifically been introduced to, and can only access resources they've been explicitly assigned. In an external (CIAM) tenant, the users are always in a customer context and have access only to the apps they've signed up for through your user flows. Beyond these, there are also service principals (apps, not humans) and managed identities, but those aren't part of the External ID guest/customer flows.