This blog will be about what kind of problems you can run into when you have multiple customers inside one active directory and you want to provide them SSO with Office 365.
Making use of modern authentication in combination with SSO can provide you with a very good user experience, except when you don’t have the option to use single sign-on. Take a look at this scenario:
- You are a hosting provider
- You have one big multi-Tenant Active Directory
- You have multiple customers, separated by OU’s in your active directory
- Each customer has its own remote desktop server(s)
- Each customer has its own Microsoft 365 tenant (of course)
- Each customer has a lot of legacy apps, which they can’t get rid of. So they are stuck for now.
- You want to use modern authentication and conditional access
Maybe you have experienced the same issues as I did. When you are using Modern Authentication there is a possibility sometimes you will be prompted for credentials when opening Office apps. Also switching terminal servers may prompt you for credentials.
Of course, when you have only one costumer, it’s a lot easier.
- install Azure Ad connect
- configure Seamless SSO.
- Configure the gpo’s necessary
But with multiple customers, who just want to save their password and not being prompted again it’s a little bit more difficult. One solution is to configure the EnableAdal (value:0) key, to make sure outlook uses legacy authentication to make sure your credentials are persistent.
When using modern authentication, your credentials will be saved as MicrosoftOffice16_Data:ADAL. Persistence will be set to: Local Machine.
When configuring the EnableAdal key, you are disabling Modern Authentication. And your credentials will be saved as MicrosoftOffice16_Data_SSPI. As shown below, persistence is enterprise and you will have the option to save your password.
It’s a quick win…but not a good win! You really don’t want to go this way!!!
So what other options do we have left? Maybe we can enable seamless SSO for the second tenant/customer?
I guess, for now, there is no option to do this (anyway not an approved Microsoft method ). Because the first tenant will create the AZUREADSSOACC computer account inside your active directory to perform the SSO you want. And you can guess what happens when you enable seamless SSO for the next customer.
If you want to know more about how SSO works, please read Microsoft their documentation.
In summary, we can’t use seamless SSO for multiple customers. There are some user voices with some good ideas to get this working for this kind of setup.
I guess going hybrid will be a good option? You can use Azure Ad hybrid in combination with your Remote desktop servers. When enrolling your devices with azure ad hybrid, SSO will be provided using PRT (primary refresh tokens), so you will get your SSO.
As you probably know, when configuring a hybrid environment. An SCP will be created, again it only will be created for the first tenant you enroll into Azure Ad Hybrid.
But what if there is a possibility to ignore this SCP and remove this setting?
And yes there is, so I configured it inside a test environment. I created some additional OU’s and placed the customer’s RDS inside their own OU.
I configured Azure Ad connect/Configured the scope/configured the Azure Ad Hybrid device option for both tenants. To be sure the SCP will not be used, I deleted the SCP values.
After I deleted the values, I created a new GPO for both customers.
ValueData: Your tenant id
ValueData: Your tenant name
When I configured the gpo’s I rebooted both servers to be sure the new settings were applied. As shown below, you will see your remote desktop servers are now Azure Ad joined.
Now you will enjoy the benefits of SSO with multiple customers from a multi-tenant active directory, but why not go further? As you have seen on one of the first pictures, I have also created gpo’s to configure
- FSlogix office containers to redirect all onedrive/sharepoint and outlook data (included in MS365 business premium)
- Office Shared activation (included in ms365 business premium)
- Automatically sign on Onedrive and KFM
- Configured gpo’s to perform some better user experience
When implementing Modern authentication on terminal servers you can run into some problems. Users can be prompted for their credentials quite often, you really don’t want this. There needs to be SSO.
When you have multiple customers inside one domain, with each their own azure ad connect instance this will be a good option to give SSO to your users.