This blog will discuss the problems you can encounter when you have multiple customers inside one active directory and want to provide them with Single Sign-On (SSO) with Office 365.
Making use of modern authentication in combination with SSO can provide the users with a very good user experience, except when you don’t have the option to use single sign-on. Take a look at this possible 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
You may have experienced the same issues as I did: When you are using Modern Authentication, you may sometimes be prompted for credentials when opening Office apps. Also, switching terminal servers may prompt you for credentials.
Of course, when you have only one customer, it’s a lot easier.
- install Entra connect
- Configure (Seamless)SSO.
- Configure the gpo’s necessary
But with multiple customers who just want to save their password and not be prompted again, it’s a little bit more difficult. So which options do we have?
1. Disable Modern Authentication
Let’s begin with the most stupid option. For this option, we need to configure the EnableAdal (value:0) key to ensure Outlook uses legacy (basic) authentication and that 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 above, 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!!! Please read my blog about how to disable Legacy auth
https://call4cloud.nl/2020/07/basic-authentication-and-the-last-crusade
2. Seamless SSO
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, it is not an approved Microsoft method ). When you configure SSO for the first tenant, the AZUREADSSOACC computer account will be created inside your active directory. You can guess what happens when you enable seamless SSO for the next customer: The AzureAdssoacc credentials will be overwritten.
If you want to know more about how SSO works, please read Microsoft’s documentation.
Azure AD Connect: naadloze single Sign-On-hoe het werkt | Microsoft Docs
In summary, we can’t use seamless SSO for multiple customers. Some user voices have good ideas for getting this working for this kind of setup.
3. Installing ADFS servers
The third option we have is, is setting up an ADFS environment to be used for each customer. But it’s not the way when you want to transform into a modern workplace or maybe, in the near future, a cloud-only environment.
Of course, I am aware there are some more complex environments and you still need to use ADFS but if you don’t have a complex environment Azure Ad Connect Pass-through authentication and Seamless SSO is the way to go. Even the NCSC is advising us since February 2019 to use cloud-native authentication.
Securing Office 365 with better configuration – NCSC.GOV.UK
Even when you don’t have the possibility to use seamless SSO as I did, there are still other options available.
4. PRT/ Azure AD Hybrid
I guess going hybrid will be a good option? You can use Entra hybrid in combination with your Windows 2016 Remote desktop servers. When enrolling your devices with Azure Ad hybrid, SSO will be provided using PRT (primary refresh token), so you will get your SSO.
However, a PRT can be used for more than SSO. It also contains information about the device itself. When using device-based conditional access rules, this device information is required to ensure the device has access, so access will be denied without a PRT.
PRT
First, some introduction to a PRT. Before we can fully understand why a PRT is necessary, I guess it may be useful to know what it is.
A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10, Windows Server 2016 and later versions, iOS, and Android devices.
A Primary Refresh Token is just like a long-term persistent Ticket Granting Ticket (TGT) you had in your old school legacy Active Directory. It is a JSON web token that will enable users to login on to their Azure AD joined device.
Once logged in, they are automatically signed in to Azure AD connected resources. But beware don’t get fooled by the name. With a normal refresh token, you only get access to what the application has been granted access to and can only be used to request access tokens for that same application.
And there is a big difference: a PRT can be used to authenticate to any application/resource! The PRT can also contain the MFA claim when MFA is needed.
So with great responsibility must come great security!
Microsoft needed to ensure the information’s safety. Please make sure your device has a TPM because the cryptographic keys will be stored within it. Once stored in the TPM, it will be very difficult for attackers to recover the cryptographic keys from the OS.
Entra ID Hybrid
Now that we fully understand what a PRT is, let’s go further with the Azure Ad / Entra ID Hybrid part. As you probably know, when configuring a hybrid environment, you will need to have Azure Ad Connect installed, and you have to make sure you have selected the Configure Azure Ad Hybrid Option
When configuring Hybrid, a Service Connection Point (SCP) will be created. Just like with the azureaddssoacc, it will only be created when you configure a tenant to enroll into Azure Ad Hybrid. When you configure a second tenant for hybrid, this setting will also be overwritten!
ADSI –> Configuration –> CN=Configuration –> CN=Services –> CN=Device Registration Configuration
You can also find the SCP value with PowerShell.
$scp = New-Object System.DirectoryServices.DirectoryEntry;
$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=domain,DC=local";
$scp.Keywords; But what if there is a possibility of ignoring this SCP and/or removing this setting?
It’s important to know when your device wants to start joining the Entra ID to become hybrid, it will try to start the “Automatic-Device-Join” Workplace Join task.
When this task starts, it will try to find the tenant id and tenant name to start joining Entra ID in this order:
- Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]
- SCP in Active Directory
Now we know it’s also possible to ensure it will look at the registry. First, I configured a test environment. I created some additional OUs and placed each customer’s RDS inside its own dedicated OU.
I also made sure I configured the following:
*Entra connects on two separate servers
*OU filtering/scope. The terminal servers must be in the scope to be synchronized with the proper Azure Ad/ Entra Connect!
*The Entra ID Hybrid device option for both tenants
*I deleted the SCP values when configuring Entra ID Hybrid for the specific tenant.
After I deleted the values, I created a new GPO for both customers and configured the two registry settings I mentioned earlier:
PATH: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD ValueName: TenantId TYPE: REG_SZ ValueData: Your tenant id SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD PATH: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD ValueName: TenantName TYPE: REG_SZ ValueData: Your tenant name SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
So it would look something like this:
When configuring the GPOs, I rebooted both servers to ensure the new settings were applied. As shown below, your remote desktop servers are now Azure Ad joined/Entra Joined.
You can check the Azure Ad Join status with DSREGCMD /status. This is also a great method for determining whether you have a Primary Refresh Token (PRT) available.
Please ensure you properly configured the ou filtering/scope and that the Entra ID connect synced successfully. You can start the delta synchronization also with PowerShell (like everything else, you can do it with PowerShell)
Start-ADSyncSyncCycle -PolicyType Delta
If the device is not in the scope of the sync was not executed, you could receive this error: 0x801c03f2. The message says it all: The device is not (yet) found in Azure Ad/Entra ID. (The Device object by the giving ID is not found)
When you are 100% sure the rds/terminal server is in the Entra ID Connect scope, and the sync was successful, but it is still showing the error above, have patience. Sometimes, it can take some time before the device certificate arrives at the device. This device certificate is needed for authentication and the PRT.
When everything is successful, you will notice the event with the ID 306 popping up in your User Device Registration event log.
With this nice event, you are good to go to check out the device cert, which I am showing below.
I created a blog about these kinds of certificates some time ago if you want to read more information.
https://call4cloud.nl/2021/04/alice-and-the-device-certificate
Of course, when you want to speed things up a little bit, you could also try to execute the dsregcmd /join in a system context.
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 in one of the first pictures, I have also created GPO’s to configure
- FSlogix office containers to redirect all one drive/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 a better user experience
Conclusion
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 Entra ID connect instance this will be a good option to give SSO to your users. I guess they will be happy.