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:

1. The Microsoft.Online.PasswordSynchronization.Rpc.dll is missing from the server, or the server is missing a .dll from the AzureADHybridAuthenticationManagement module

2. 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. Please uninstall and try again.”

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:

1. Navigate to the entra.microsoft.com admin portal.

2. Go to “Traffic forwarding.”

3. 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

If the Microsoft Entra Connect (Azure AD Connect) wizard fails to install, the following errors may occur:

An internal problem has occurred. It appears that you are resuming a scenario that was not completed previously during installation. Please uninstall and try again. No registered products found. The synchronization service scheduler is suspended until this setup wizard is closed. Learn more about ‘Scheduler and installation wizard.

To resolve these issues, follow these steps:

When publishing an ASP.NET Core web application to Azure, some users may encounter this error:

“Error 500.0 — ANCM In-Process Handler Load Failure”

If you have an application that runs locally but fires this error when published to Azure, here are steps that should resolve this issue:

1. If your application does not include a web.config file, add the following web.config file to the solution:

If you attempted to use the “leave tenant” button in the Microsoft Entra portal and your account is a personal Microsoft account that is a guest user of that tenant, you need to leave the directory using the My Account page instead of the Microsoft Entra portal page.

If this is the case, you can follow these steps to leave the tenant:

1. Turn off all incognito or private session on your browser.

If you are not receiving the weekly digest emails for Privileged Identity Management (PIM), you need to make sure that you have a valid “Email” or “Alternate email” configured. Once the email is configured, Global admins, security admins, and security readers will automatically receive weekly digest mails.

As an administrator, you can choose the users assigned to receive the email and configure the weekly digest email in the Microsoft Entra admin center > Protection > Identity Protection > Weekly digest. The users need appropriate permissions to view any linked reports. https://portal.azure.com/#blade/Microsoft_AAD_IAM/IdentityProtectionMenuBlade/WeeklyDigest

Have you tried to sign into an Azure tenant and selected the correct directory, only to be redirected to an entirely different directory from the one you chose? If you are having trouble switching directories in Azure Active Directory, here are the steps to resolve this issue.

Problem

When attempting to switch directories or sign into a particular directory, Azure AD automatically signs you into your default or startup directory. If your account has been removed from the default directory, this can result in a chicken and egg scenario where your account keeps trying to sign into a directory where you no longer have access, but you can’t select a different default because you can’t sign in.

In Azure AD Connect, the sourceAnchor attribute connects an on-premises object to a cloud object. It ensures that a hybrid object has the same identity both on-premises and in Azure. After the sourceAnchor attribute has been set, it is best practice to avoid updating the sourceAnchor attribute value unless it is absolutely necessary to do so. Attributes such as UserPrincipalName or email, for example, should not be used, since they can change if a user’s user name or email changes.

In 2019 I answered a question on Stack Overflow about the difference between App Registrations and Enterprise Applications in Azure Active Directory. Two years later I still see questions about the differences between these two terms, as well as questions about how the term “Service Principal” relates to each. The purpose of this blog post is to define these three terms and clarify how they differ from each other.

App Registrations

The goal of this post is to help clarify some confusion about setting up Pass-Through Authentication in Azure AD Connect and outline the steps for completing the Azure AD Connect Wizard. Stepping through the AAD Connect Wizard and setting up PTA may seem simple at first, but the tool has some tricky idiosyncrasies that are worth noting. The below steps will help you work through them.

When you have added a custom domain in the Azure Portal and are ready to configure the connect wizard, follow these steps to sync your on-premises directory with Azure Active Directory.

Over 300 people have asked questions on Stack Overflow about how to configure Reply URLs for .NET web apps in the Azure Portal. Reply URLs are a very simple concept, but their setup in the Azure Portal is not necessarily intuitive.

When you register an Azure AD application you are required to configure a reply URL, which by default takes its value from the sign-on URL entered during the app registration.