How to Fix Set-AzureADKerberosServer Connection Errors in Windows Hello for Business
Resolve the Set-AzureADKerberosServer 'Failed to connect to domain' and 'Failed to read secrets' errors when setting up Windows Hello for Business cloud Kerberos trust in a hybrid Microsoft Entra ID environment.
- Difficulty
- Advanced
- Time required
- 20-30 minutes
- Steps
- 7
- Platform
- Windows Hello for Business
Table of contents
Quick Answer
Go to the stepsThe Set-AzureADKerberosServer connection errors almost always come from running the cmdlet on the wrong machine or passing the domain credential in the wrong form. Run it on your Microsoft Entra Connect server, which carries the required Microsoft.Online.PasswordSynchronization.Rpc.dll dependency, and either omit -DomainCredential so your current Kerberos login is used, or supply it in user@domain (UPN) format rather than domain\username.
- Run PowerShell as administrator on the Microsoft Entra Connect server.
- Install or update the AzureADHybridAuthenticationManagement module (TLS 1.2).
- Confirm DC connectivity and that your account has Hybrid Identity Admin + Domain Admin rights.
- Run Set-AzureADKerberosServer, omitting -DomainCredential or passing it in UPN format.
- Verify with Get-AzureADKerberosServer that KeyVersion matches CloudKeyVersion.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName admin@contoso.onmicrosoft.comExpected result: The cmdlet completes without a connection error, and Get-AzureADKerberosServer returns the new Kerberos server object with matching KeyVersion and CloudKeyVersion.
Key takeaways
- You'll learn why Set-AzureADKerberosServer fails with 'Failed to connect to domain' or 'Failed to read secrets from the domain', and how to run it correctly to create the Microsoft Entra Kerberos server object for Windows Hello for Business cloud Kerberos trust.
- Without a working Microsoft Entra Kerberos server object, users signing in with FIDO2 keys or Windows Hello for Business cloud trust can't obtain Kerberos tickets for on-premises resources, so file shares and legacy apps stop working.
- Run Set-AzureADKerberosServer on the Entra Connect server and never pass -DomainCredential as domain\username - that combination causes most connection errors.
Introduction
If you're standing up Windows Hello for Business cloud Kerberos trust, Set-AzureADKerberosServer is the command that creates the Microsoft Entra Kerberos server object your users rely on to get Kerberos tickets for on-premises resources. It's also the command that most often stops administrators cold with Failed to connect to domain or Failed to read secrets from the domain. In almost every case the cmdlet itself is fine - the problem is the machine it runs on or the way the domain credential is passed. This guide walks the fix in order: get onto the right server, confirm connectivity and roles, run the cmdlet with the correct credential mode, clear the secrets error, handle multi-domain forests, and verify the result.
Who this is for: Hybrid identity administrators and MSPs configuring Windows Hello for Business cloud Kerberos trust in a hybrid Microsoft Entra ID (formerly Azure AD) environment.
Before you start
- Access
- Administrative PowerShell on the Microsoft Entra Connect server (or a server carrying the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency), plus network access to a writable domain controller in the target domain.
- Required roles
- Hybrid Identity Administrator (Microsoft Entra ID)
- Domain Admins in the target domain
- Enterprise Admins for forest-wide configuration
- Domain Admins in the target on-premises domain
- Environment
- Windows Server 2016 or later domain controllers with the required Kerberos patches installed and AES256_HMAC_SHA1 enabled, plus a working Microsoft Entra Connect sync.
- Vendor
- Microsoft
- Administrator permissions required
- Backup required
Steps verified against Microsoft Learn documentation updated July 2025; the commands were not run in a lab for this article.
About 20-30 minutes once the prerequisites are in place.
Critical: Take a backup before removing an existing Kerberos object
If you remove and recreate the AzureADKerberos object in a live environment, cloud-trust and FIDO2 sign-ins can break. Take a current Active Directory system state backup and record the output of Get-AzureADKerberosServer before deleting anything so you can recover.
Warning: Run it on the correct server
Creating the Kerberos object on a machine that lacks the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency (for example, a bare domain controller) is a common cause of the connection and 'failed to read secrets' errors. Use the Microsoft Entra Connect server.
1Run PowerShell on the Microsoft Entra Connect Server
Make sure you're on a machine that has the dependency the cmdlet needs - the most common cause of the error.
Sign in to your Microsoft Entra Connect server (or another server that has the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency installed) and open PowerShell as administrator. Set-AzureADKerberosServer publishes the Kerberos object through this RPC dependency, so running it on a bare domain controller that lacks the DLL is a frequent cause of Failed to connect to domain and Failed to read secrets from the domain. You can install the module on any machine that can reach your DC, but the object must be *created* from a machine that carries this dependency.
whoami /groupsExpected result: You have an elevated PowerShell session on the Entra Connect server, and whoami /groups shows your account is a member of the required Domain Admins / Enterprise Admins groups.
Note
If you later see System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Online.PasswordSynchronization.Rpc.dll', you're on a machine without the dependency - switch to the Entra Connect server.
2Install or Update the AzureADHybridAuthenticationManagement Module
Ensure the cmdlet is present and current, and avoid the retired AzureAD module.
Enable TLS 1.2 for the PowerShell Gallery, then install (or update) the module that provides Set-AzureADKerberosServer. You do not need the legacy AzureAD module - it was retired on 30 March 2025 and isn't required for this task. Only AzureADHybridAuthenticationManagement is needed.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
# If it is already installed, update instead:
Update-Module AzureADHybridAuthenticationManagement
Get-Module -ListAvailable AzureADHybridAuthenticationManagement | Select-Object Name, VersionExpected result: Get-Module -ListAvailable lists the AzureADHybridAuthenticationManagement module with a current version number and no install errors.
Note
As of module update 2.3.331.0, the module no longer installs the AzureADPreview module.
3Verify Prerequisites, Roles, and Domain Connectivity
Rule out patch level, encryption, network, and permission problems before running the cmdlet.
Confirm your domain controllers run Windows Server 2016 or later with the required Kerberos patches and AES256_HMAC_SHA1 enabled, then test reachability to a writable DC on the Kerberos, LDAP, and SMB/RPC ports. Confirm your account holds Domain Admins (and Enterprise Admins for a forest-wide setup) on-premises and the Hybrid Identity Administrator role in Microsoft Entra ID.
$domain = $env:USERDNSDOMAIN
$dc = (Get-ADDomainController -Discover -Domain $domain).HostName[0]
Test-NetConnection -ComputerName $dc -Port 88 # Kerberos
Test-NetConnection -ComputerName $dc -Port 389 # LDAP
Test-NetConnection -ComputerName $dc -Port 445 # SMB / RPC
nltest /dsgetdc:$domain /keylist /kdc
whoami /groupsExpected result: All three Test-NetConnection checks return TcpTestSucceeded : True, nltest discovers a domain controller, and whoami /groups confirms your privileged group membership.
Note
The /keylist switch requires Windows 10 v2004 (and the Windows Server equivalents) or later. Least privilege in Entra ID is Hybrid Identity Administrator - Global Administrator also works but isn't required.
4Run Set-AzureADKerberosServer with the Correct Credential Mode
Create the Kerberos object using the credential form that avoids the connection error.
Pick the credential mode that matches your environment. The Failed to connect to domain error is most often caused by the value passed to -DomainCredential: when supplied as domain\username, the RPC bind to the DC falls back to NTLM and fails. Either omit -DomainCredential (the current Windows/Kerberos login is used to reach the DC) or supply it in UPN form (user@domain). If your tenant enforces MFA, use -UserPrincipalName for the cloud sign-in instead of a password-based -CloudCredential.
$domain = $env:USERDNSDOMAIN
# A) MFA-enforced tenant, domain-joined admin (recommended fix):
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName "admin@contoso.onmicrosoft.com"
# B) Prompt for both, modern auth for the cloud:
$domainCred = Get-Credential # enter as user@domain, NOT domain\user
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName "admin@contoso.onmicrosoft.com" -DomainCredential $domainCred
# C) Classic (no MFA): prompt for cloud, use current login for AD:
$cloudCred = Get-Credential
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCredExpected result: The cmdlet returns to the prompt without a 'Failed to connect to domain' error. On the first Entra Kerberos command you're prompted to sign in to Microsoft Entra ID first.
Note
Replace the UPN and domain with your own. To target a non-commercial cloud, first run Get-AzureADKerberosServerEndpoint, then set it with Set-AzureADKerberosServerEndpoint -TargetEndpoint <n>.
5Resolve 'Failed to Read Secrets from the Domain'
Clear the related secrets error that blocks object creation.
If the cmdlet reaches the domain but returns Failed to read secrets from the domain, work the known causes in order: temporarily disable the FIPS security policy (you can re-enable it afterward), confirm you're running on the Entra Connect server so the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency is present, and make sure the account has default administrative permissions. If accounts are in the Protected Users group, sign in to the Entra Connect server as another domain admin and omit -DomainCredential so the current user's Kerberos ticket is used.
# Re-run after temporarily disabling FIPS policy:
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCredExpected result: After disabling FIPS and running from the correct server, the cmdlet completes and no longer reports 'Failed to read secrets from the domain'.
Note
Re-enable FIPS policy once the object is created. Detailed trace logs are written under C:\ProgramData\AADConnect\.
6Handle Multi-Domain and Child-Domain Forests
Avoid the child-domain trust errors specific to multi-domain forests.
In a forest with child domains, create the object in each domain, and run from a machine in the target domain using that domain's Domain Admin. To avoid LsaCreateTrustedDomainEx 0x549 and the UserAccount.SecondaryKrbTgtNumber Value:0 error, run the command on the root domain with the -SetupCloudTrust parameter, then run it again on the child domain without -SetupCloudTrust.
# On the ROOT domain (include -SetupCloudTrust):
Set-AzureADKerberosServer -Domain $rootDomain -UserPrincipalName $upn -DomainCredential $domainCred -SetupCloudTrust
# On the CHILD domain (omit -SetupCloudTrust):
Set-AzureADKerberosServer -Domain $childDomain -UserPrincipalName $upn -DomainCredential $childDomainCredExpected result: Each domain gets its own KerberosDomain object in Microsoft Entra ID without the 0x549 or SecondaryKrbTgtNumber errors.
Note
Use a Domain Admin scoped to the child domain rather than an Enterprise Admin from the root, to avoid sAMAccountName conflicts.
7Verify the Kerberos Server Object
Confirm the object exists and is consistent between Active Directory and Entra ID.
Read back the Kerberos server and confirm the on-premises and cloud copies agree. When prompted for domain credentials, use the UPN format so the RPC bind to the DC uses Kerberos rather than NTLM. Also confirm the AzureADKerberos computer object exists in the Domain Controllers OU and the disabled krbtgt_AzureAD user exists under CN=Users.
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential (Get-Credential)
Get-ADComputer -Identity AzureADKerberos -Properties DistinguishedName
Get-ADUser -Identity krbtgt_AzureAD -Properties Enabled, DistinguishedNameExpected result: Get-AzureADKerberosServer returns the object with the on-premises KeyVersion equal to CloudKeyVersion, and the AzureADKerberos computer and krbtgt_AzureAD user objects are present.
Note
If KeyVersion and CloudKeyVersion differ, publishing to Entra ID didn't complete - re-run the create command from the Entra Connect server.
How to Confirm the Microsoft Entra Kerberos Server Is Working
Verify fix
A successful fix means Set-AzureADKerberosServer completes without a connection error and the Kerberos server object exists in both directories. Run Get-AzureADKerberosServer and compare the on-premises properties with the cloud ones: the ID must match CloudId, the DomainDnsName must match CloudDomainDnsName, and - most importantly - KeyVersion must equal CloudKeyVersion. In Active Directory, the AzureADKerberos computer object should sit in the Domain Controllers OU, and krbtgt_AzureAD should exist as a disabled user under CN=Users. Once these agree, Windows Hello for Business cloud trust and FIDO2 sign-ins can obtain Kerberos tickets for on-premises resources.
Normal result: Get-AzureADKerberosServer returns an object whose KeyVersion equals CloudKeyVersion, with the AzureADKerberos computer object in the Domain Controllers OU and a disabled krbtgt_AzureAD user under CN=Users.
Abnormal result: If KeyVersion and CloudKeyVersion differ, or Get-AzureADKerberosServer returns nothing, the object wasn't published to Entra ID - usually because the create step ran on a machine without the RPC dependency or against the wrong domain.
KeyVersion parity
192272 (on-prem) = 192272 (cloud)
The on-premises and cloud key versions match, confirming the object is published correctly.
Troubleshooting
Set-AzureADKerberosServer : Failed to connect to domain
Warning
Cause: The value passed to -DomainCredential is in domain\username form, so the RPC bind to the DC falls back to NTLM and fails; or the credential otherwise interferes with the connection.
Omit -DomainCredential so the current Windows/Kerberos login is used, or supply it in UPN (user@domain) format. Run from a domain-joined machine as a Domain Admin.
Set-AzureADKerberosServer : Failed to read secrets from the domain
Warning
Cause: FIPS policy is enabled, the account lacks default administrative permissions, or the machine is missing the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency.
Temporarily disable FIPS policy and re-run, confirm you're on the Entra Connect server, and ensure the account has default admin rights. Re-enable FIPS afterward.
Could not load file or assembly 'Microsoft.Online.PasswordSynchronization.Rpc.dll'
Warning
Cause: The cmdlet is being run on a machine that lacks the RPC dependency - commonly a bare domain controller.
Run the create command on the Microsoft Entra Connect server, or another server that has this dependency installed.
LsaCreateTrustedDomainEx 0x549 or UserAccount.SecondaryKrbTgtNumber Value:0 on a child domain
Warning
Cause: The command was run against a child domain with -SetupCloudTrust, or from the wrong domain context.
Run the command on the root domain with -SetupCloudTrust, then on the child domain without -SetupCloudTrust, using that domain's Domain Admin from a machine in the target domain.
The MFA / modern-auth prompt fails when using -CloudCredential
Note
Cause: The tenant enforces modern authentication (MFA, FIDO2, or smart card), which a password-based -CloudCredential can't satisfy.
Use -UserPrincipalName with the Hybrid Identity Administrator UPN so the cmdlet opens an interactive modern-auth sign-in instead.
Frequently asked questions
Why does Set-AzureADKerberosServer say 'Failed to connect to domain'?
Most often because -DomainCredential was passed as domain\username, which forces an NTLM RPC bind to the DC that fails. Omit -DomainCredential to use your current Kerberos login, or pass it in user@domain (UPN) format, and run from the Entra Connect server.
Which role do I need in Entra ID to run it?
The least-privileged cloud role is Hybrid Identity Administrator; Global Administrator also works but isn't required. On-premises you need Domain Admins in the target domain, plus Enterprise Admins for a forest-wide setup.
Can I run Set-AzureADKerberosServer on a domain controller?
It should be created on the Microsoft Entra Connect server, or another server that has the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency. A bare domain controller often lacks that DLL, which triggers the connection and 'failed to read secrets' errors.
Do I still need the AzureAD PowerShell module?
No. The legacy AzureAD module was retired on 30 March 2025 and isn't needed here. Install only AzureADHybridAuthenticationManagement, which provides the Set-AzureADKerberosServer cmdlet.
How do I run it if my tenant enforces MFA?
Use the -UserPrincipalName parameter with a Hybrid Identity Administrator UPN. The cmdlet then opens an interactive modern-authentication sign-in that supports MFA, FIDO2, and smart cards, rather than a password-based -CloudCredential.
How do I verify the Kerberos server object was created?
Run Get-AzureADKerberosServer and confirm KeyVersion equals CloudKeyVersion. In Active Directory, the AzureADKerberos computer object should appear in the Domain Controllers OU and krbtgt_AzureAD should exist as a disabled user under CN=Users.
Conclusion
Set-AzureADKerberosServer connection errors are rarely about the cmdlet itself - they come down to where you run it and how you pass credentials. Run it from the Microsoft Entra Connect server so the RPC dependency is present, omit -DomainCredential or use UPN format to keep the DC bind on Kerberos, and temporarily disable FIPS if you hit the 'failed to read secrets' error. Then verify that KeyVersion matches CloudKeyVersion before moving on to the client-side policy.
Run Set-AzureADKerberosServer on the Entra Connect server and never pass -DomainCredential as domain\username - that combination causes most connection errors.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName admin@contoso.onmicrosoft.comSources3
