Last Updated on April 7, 2022 by rudyooms
UPDATE 26-07-2021 I noticed I did not explained how important the PRT is... so I added it!. UPDATE 22-05-2021 After we configured Azure Ad Hybrid for a new customer in our multi-tenant AD because they needed SSO and we don't want to use ADFS, I decided to update my blog about it. It was missing some important and background information.
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 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
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 customer, 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 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 make sure outlook uses legacy (basic) 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 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
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 not an approved Microsoft method ). Because when you configure SSO for the first tenant it will create the AZUREADSSOACC computer account 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 their documentation.
Azure AD Connect: naadloze single Sign-On-hoe het werkt | Microsoft Docs
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.
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 Azure Ad 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 tokens), so you will get your SSO.
But SSO is not the only thing a PRT can be used for. The PRT also contains information about the device itself. When using device-based conditional access rules, this device information is required to make sure the device has access so, without a PRT, access will be denied.
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 comes a big difference, a PRT can be used to authenticate to any application/resource! And the PRT also can contain the MFA claim when MFA is needed.
So with great responsibility, must come great security!
So Microsoft needed to make sure the information is safe. So please make sure your device has a TPM because the cryptographic keys will be stored within that TPM. Once stored in the TPM will make it very difficult for attackers to recover the cryptographic keys from the OS.
Azure Ad Hybrid
Now we fully understand what a PRT is let’s go further with the Azure Ad 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 you have configured Hyrbid, a Service Connection Point (SCP) will be created. Just like with the azureaddssoacc it only will 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 to ignore this SCP and/or remove this setting?
It’s important to know when your device wants to start joining the azure ad 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 azure ad 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 make sure it will look at the registry first I configured a test environment. I created some additional OU’s and placed each customer’s RDS inside their own dedicated OU.
I also made sure I configured:
*Azure Ad connect on two separate servers
*OU filtering/scope. The terminal servers need to be in the scope to be synchronized with Azure Ad Connect!
*The Azure Ad Hybrid device option for both tenants
*I deleted the SCP values each time when I configured Azure Ad Hybrid for the specific tenant.
After I deleted the values, I created a new GPO for both customers and configured the 2 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 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.
You can check the Azure Ad Join status with DSREGCMD /status. It is also a great method to determine if you have a Primary Refresh Token (PRT) available.
Please make sure you configured the ou filtering/scope properly and Azure Ad 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 or 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.
When you are 100% sure the rds/terminal server is in the Azure Ad connect scope and the sync was successful and 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
And with this nice event, you are good to go to check out the device cert like I am showing below.
If you want to read some more information about these kinds of certificates, I created a blog about it some time ago.
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 some 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 azure ad connect instance this will be a good option to give SSO to your users. I guess they will be happy
