Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Azure AD Connect and On-Prem ADFS federated with multiple partner organization

Brass Contributor

Scenario:

We have an on-prem ADFS which is configured to federate with couple of partner organizations. The federated authentication with both our partners works well in On-Prem. Now we want to use this ADFS as authentication mechanism for Office 365.

 

Questions: 

  1. Users of our AD will be synched with the help of Azure AD connect. Do we really need to sync the users of partner organization's AD as well to let them access our Office 365 tenant(shared SharePoint sites)? if it is required, what should be the approach?
  2. If partner-A and partner-B needs to access Office 365 SharePoint Site, what kind of license would they require? Can they be considered as external user? Would they require to have their own Office 365 tenant?
  3. We assume that once the ADFS federation with Office 365 configured, the authentication will happen in following way
    • Partner-A user tries to access SharePoint Online site URL that i've shared
    • Office 365 will route the request to on-prem ADFS of my organization
    • My on-prem ADFS will then pass the request to Partner-A ADFS
    • The user will get authenticated with Partner-A ADFS and returned to My ADFS with the token
    • My ADFS will replace Partner-A's token with its own token and send back the user to Office 365
    • User successfully accesses the shared SharePoint Online site

            Is this the correct understanding?

12 Replies

Hi Atul,

 

You should not use your ADFS to authenticate partner users because you will need to validate their domain on your Office 365 as an accepted and validated domain.

Thanks Nuno for your quick response!

 

Can you point me to an article where this or similar kind of scenario is explained in detail? I couldn't find any good resource/documentation around this scenario and i believe this must be quite common requirement for many big enterprises.

I think there is no article of that, but you can only validate your domains on Office 365 not your partner and that is a requisite of ADFS.

 

Bellow is an article of implementing ADFS https://blogs.technet.microsoft.com/rmilne/2014/04/28/how-to-install-adfs-2012-r2-for-office-365/

@Atul Moghe Did you get any solution for this scenario. 

hi,

1/ In sharepoint, you can add a external user, the user of partner organisation not need sync to let them access. But is just for sharing document.

2/ if you use the 1 solution, not need licence.

3/ For give access at partner org, you have few solutions,

- You can use Azure BtoB (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-what-is-azure-ad-b2b)
- you can federated their on-premise AD with your tenant ( it's very intrusive for your organisation)



Easiest implementation would be your partners also sync their users to Azure AD.  Then you can invite them as a guest to your tenant and then they will be available to add a users in Office 365.

Hi,

 

I would sync your users to Azure AD and simply invite your partners' users to SharePoint sites. If done so, the answers are as follows:

  1. No, you do not need to sync them to Azure AD.
  2. No need for any license, just invite them as external users. To login, your partners' invited users do require either a Microsoft Account (outlook.com, hotmail.com, etc.) or Azure AD account (Office 365 etc.).
  3. There is no need to any AD FS scenario here. When partners are external users, Office 365 will handle all the authentication

For security reasons, I suggest that you run the following PowerShell command in your tenant. It forces the external users to login with the same email address the invitation was sent to.

Set-SPOTenant -RequireAcceptingAccountMatchInvitedAccount $true
I'd assume they wouldn't want them using a Microsoft account for account management purposes. You can signup for a Microsoft account with any email address. If they do it with their work email address, two things would happen that would be issues with a lot of organizations. 1. It would be a separate account with a separate password. 2. If they left the partner company, they would still be able to login with the Microsoft account after the company partner account is deactivated or password changed.

The partner would need their own Azure AD with on-prem accounts synced or their own ADFS and you would federate your Azure AD with that.
Good point, it would be better from the management point-of-view to have all users in Azure AD in partner's own tenant.

However, there is no need to federate anything, Office 365 takes care of authentication. Besides, if the partner is already using Office 365, their domain is registered to their tenant it cannot be federated to other tenants.
I think you might be mixing up federation with sync. You can't sync a domain to more than one tenant but you can absolutely federate with other directories. If they are in another Azure tenant, you have two options, invite them as external users to your tenant or setup federation between two tenants using custom policies. If you don't mind external users in your directory, then inviting them as external users is by far the easiest of the two options.

The term federation means many things in Office 365/Azure AD, so I think we are simply talking about different things here.

 

What I meant by federation is that you either create a new federated domain to Office 365 or convert an existing one to federated:

 

# Create a new federated domain
New-MsolFederatedDomain -DomainName mydomain.com
# Convert a domain to federated
Convert-MsolDomainToFederated -DomainName mydomain.com

This naturally requires that the domain is registered to that Office 365 tenant. Moreover, what the federation does is that it only authenticates the user. To log in and use Office 365 services, there must be a matching user object in the Office 365 tenant. 

 

 

I suppose by federation you meant something like Azure B2B Collaboration?

I mean federation as defined, which is joining two distinct or disconnected directories. The purpose is so you do not have to create and manage users in the other directory. The user account exists and is maintained in one directory, but can access resources trusted by another directory. You can setup a B2B tenant if you'd like, but that is just one way to accomplish it. You are correct that a user object has to exist in the Azure AD tenant to login to O365, that is what the invite as external user from another Azure AD tenant option does. This only makes the user available to be granted access to applications under the tenant, but their user account still exists and is maintained in the other tenant.