Forum Discussion
Cloud Kerberos Trust with 1 AD and 6 M365 Tenants?
Hi,
we would like to enable Cloud Kerberos Trust on hybrid joined devices ( via Entra connect sync)
In our local AD wie have 6 OUs and users and devices from each OU have a seperate SCP to differnt M365 Tenants. I found this Article to configure the Cloud Kerberos Trust .
Set-AzureADKerberosServer
1
2
The Set-AzureADKerberosServer PowerShell cmdlet is used to configure a Microsoft Entra (formerly Azure AD) Kerberos server object. This enables seamless Single Sign-On (SSO) for on-premises resources using modern authentication methods like FIDO2 security keys or Windows Hello for Business.
Steps to Configure the Kerberos Server
1. Prerequisites
Ensure your environment meets the following: Devices must run Windows 10 version 2004 or later. Domain Controllers must run Windows Server 2016 or later. Install the AzureADHybridAuthenticationManagement module: [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12 Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
2. Create the Kerberos Server Object
Run the following PowerShell commands to create and publish the Kerberos server object:
Prompt for All Credentials:
$domain = $env:USERDNSDOMAIN
$cloudCred = Get-Credential -Message 'Enter Azure AD Hybrid Identity Administrator credentials'
$domainCred = Get-Credential -Message 'Enter Domain Admin credentials'
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
As I understand the process, a object is created in local AD when running
Set-AzureADKerberosServer
What happens, if I run the command multiple times, for each OU/Tenant. Does this ovveride the object, or does it create a new objects?
Hi,
This is a very important question, and your scenario requires careful consideration before running the command.
Short answer:
Set-AzureADKerberosServer is not OU-based and not SCP-based.
It creates a single Cloud Kerberos Trust configuration per Active Directory domain, not per tenant.How Cloud Kerberos Trust works
When you run:
Set-AzureADKerberosServer -Domain
The cmdlet:
– Creates (or configures) an AzureADKerberos object in the on-prem AD
– Publishes the Entra ID tenant public key into AD
– Establishes the trust required for Windows Hello for Business Cloud Kerberos TrustThe object is created at the domain level, typically under:
CN=AzureADKerberos, CN=System, DC=domain,DC=com
It is not scoped per OU.
It is not tied to the SCP.
It is not multi-tenant aware.Critical point in your design
You currently have:
– One on-prem AD domain
– Six Microsoft 365 tenants
– Separate SCPs per OU pointing to different tenantsCloud Kerberos Trust is designed for a 1 AD domain → 1 Entra ID tenant model.
It does not support multiple tenants sharing the same AD domain for Cloud Kerberos Trust.
What happens if you run Set-AzureADKerberosServer multiple times?
If you run it for Tenant A:
– The AzureADKerberos object is created/configured using Tenant A’s key.
If you then run it again for Tenant B:
– It does not create a second object.
– It updates (overwrites) the existing AzureADKerberos object.
– The trust is now configured for Tenant B.Result:
Only the last configured tenant will work with Cloud Kerberos Trust.
Previously configured tenants will effectively lose Cloud Kerberos Trust functionality.Impact
In a multi-tenant hybrid setup like yours:
– You cannot have six separate Cloud Kerberos Trust configurations within the same AD domain.
– Running the command multiple times will overwrite the configuration each time.
– Windows Hello for Business Cloud Trust will only function for the most recently configured tenant.Conclusion
Set-AzureADKerberosServer does not create multiple objects per tenant.
It configures a single domain-level object.
Re-running it for another tenant overwrites the previous configuration.Cloud Kerberos Trust is not supported in a single AD domain connected to multiple Entra ID tenants via separate SCPs.
You would need to reconsider the architecture if Cloud Kerberos Trust is required across all tenants.
3 Replies
Hi,
This is a very important question, and your scenario requires careful consideration before running the command.
Short answer:
Set-AzureADKerberosServer is not OU-based and not SCP-based.
It creates a single Cloud Kerberos Trust configuration per Active Directory domain, not per tenant.How Cloud Kerberos Trust works
When you run:
Set-AzureADKerberosServer -Domain
The cmdlet:
– Creates (or configures) an AzureADKerberos object in the on-prem AD
– Publishes the Entra ID tenant public key into AD
– Establishes the trust required for Windows Hello for Business Cloud Kerberos TrustThe object is created at the domain level, typically under:
CN=AzureADKerberos, CN=System, DC=domain,DC=com
It is not scoped per OU.
It is not tied to the SCP.
It is not multi-tenant aware.Critical point in your design
You currently have:
– One on-prem AD domain
– Six Microsoft 365 tenants
– Separate SCPs per OU pointing to different tenantsCloud Kerberos Trust is designed for a 1 AD domain → 1 Entra ID tenant model.
It does not support multiple tenants sharing the same AD domain for Cloud Kerberos Trust.
What happens if you run Set-AzureADKerberosServer multiple times?
If you run it for Tenant A:
– The AzureADKerberos object is created/configured using Tenant A’s key.
If you then run it again for Tenant B:
– It does not create a second object.
– It updates (overwrites) the existing AzureADKerberos object.
– The trust is now configured for Tenant B.Result:
Only the last configured tenant will work with Cloud Kerberos Trust.
Previously configured tenants will effectively lose Cloud Kerberos Trust functionality.Impact
In a multi-tenant hybrid setup like yours:
– You cannot have six separate Cloud Kerberos Trust configurations within the same AD domain.
– Running the command multiple times will overwrite the configuration each time.
– Windows Hello for Business Cloud Trust will only function for the most recently configured tenant.Conclusion
Set-AzureADKerberosServer does not create multiple objects per tenant.
It configures a single domain-level object.
Re-running it for another tenant overwrites the previous configuration.Cloud Kerberos Trust is not supported in a single AD domain connected to multiple Entra ID tenants via separate SCPs.
You would need to reconsider the architecture if Cloud Kerberos Trust is required across all tenants.
Thanks for your answer. I expected this, but hoped for a solution with our scenario.
I just configured this in my organization (we only have 1 tenant) but keep in mind, any AD user assigned an Admin group in AD (Domain Admin, Schema Admin, Enterprise Admin, etc.) their Cloud Kerberos Trust ticket cannot be sent to Entra
So lets say you are setting this up for Windows Hello biometrics or pin use into the local workstation and to be used for browser authentication, browser will not work because the credential cannot be passed into Entra for admin.
Hope this helps!
I spent a ton of time thinking my setup was misconfigured
