Forum Discussion
Cloud Kerberos Trust with 1 AD and 6 M365 Tenants?
- Mar 03, 2026
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