Earlier this week I was attempting to create an Entra ID Kerberos server object, and I kept running into these errors: Set-AzureADKerberosServer : Failed to read secrets from the domain Set-AzureADKerberosServer : Failed to connect to domain Normally these errors occur for these reasons: The Microsoft.Online.PasswordSynchronization.Rpc.dll is missing from the server, or the server is missing a .dll from the AzureADHybridAuthenticationManagement module The cloud credentials and the domain credentials are entered incorrectly.

This morning while I was sipping my tea, I pondered life’s most important question: “Why aren’t my users synchronizing from my on-premises Active Directory to my Microsoft Entra ID tenant?” During my initial Password Hash Sync attempt, my synchronization service account was created, but none of the users synchronized, and the installation service timed out with this error: “An internal problem has occurred. It appears that you are resuming a scenario that was not completed previously during installation.

In the Global Secure Access client Health Check, the “Breakglass mode is enabled” error typically indicates an issue with the Traffic forwarding configuration in the Microsoft Entra admin center. If the Advanced Diagnostics of the Global Secure Access client displays this error, you can resolve it by following these steps: Navigate to the entra.microsoft.com admin portal. Go to “Traffic forwarding.” Verify that the traffic forwarding profiles are enabled.

If the Global Secure Access client will not install or appear under your list of Programs or registry keys, there is likely an issue with the domain-join status of your machine. If this is the case, you will be able to download the .exe and receive an “Installation successful” message, but you will be prompted to repair or uninstall the client. Repair or Uninstall prompt loop To resolve this issue, first verify that your machine is either Entra ID joined or Microsoft Entra hybrid joined.

“The request timed out.” If this error occurs when attempting to ping between VMs from within the same VNET in Azure, it’s likely that either the Windows Firewall or the Network Security Group are blocking the ICMP ping traffic. Otherwise, you might be attempting to reach a VM that does not have a public IP assigned, or you could be reaching out to a private IP that is outside of the Azure Virtual Network.