Troubleshooting Microsoft Entra Hybrid Sync: GMSA Creation Failure Due to KDS Issue

Table of Contents

Microsoft Entra Hybrid Sync is a critical component for organizations managing hybrid identity environments, bridging on-premises Active Directory with Microsoft Entra ID. The seamless operation of this synchronization relies heavily on the Microsoft Entra Connect Provisioning Agent, which uses Group Managed Service Accounts (gMSAs) for secure and automated service execution. This guide addresses a specific, yet impactful, troubleshooting scenario where the provisioning agent fails to install due to an inability to create the necessary gMSA, often pointing to an underlying Key Distribution Service (KDS) problem on domain controllers.

When attempting to deploy the Microsoft Entra Connect Provisioning Agent, administrators may encounter persistent installation failures, particularly when the system is unable to set up the required service account. This situation not only halts the agent’s deployment but also obstructs the overall hybrid identity synchronization process, impacting user and group provisioning between your on-premises Active Directory and Microsoft Entra ID. Understanding the root cause of these failures is paramount for maintaining a robust and secure hybrid identity infrastructure.

Understanding the Microsoft Entra Connect Provisioning Agent and gMSAs¶

The Microsoft Entra Connect Provisioning Agent serves as the bridge between your on-premises Active Directory and the Microsoft Entra cloud service, facilitating the synchronization of identity data. This agent is designed for efficiency and security, utilizing Group Managed Service Accounts (gMSAs) to execute its operations. gMSAs are a special type of service account introduced in Windows Server 2012 that offer enhanced security features and simplified management compared to traditional service accounts.

Group Managed Service Accounts (gMSAs) provide several significant advantages. They eliminate the need for manual password management, as their passwords are automatically changed by the Windows operating system at regular intervals, enhancing security and reducing the administrative burden. Furthermore, gMSAs can be used across multiple servers, making them ideal for distributed service architectures like the Microsoft Entra Connect Provisioning Agent, which might run on several machines for high availability. Their integration with Kerberos authentication also ensures secure service principal name (SPN) management. The inability to create this specialized account effectively renders the provisioning agent inoperable.

Essential Prerequisites for Cloud Provisioning Agent Installation¶

Before embarking on the installation of the Cloud Provisioning Agent, it is crucial to ensure that all preliminary requirements are met. These prerequisites lay the foundation for a successful deployment and help prevent common installation pitfalls. Failing to meet any of these conditions can lead to unexpected errors, including those related to gMSA creation.

Key prerequisites typically include:

• Domain Controller Health: All domain controllers must be healthy, fully functional, and replicating Active Directory changes correctly.
• Network Connectivity: Robust network connectivity to domain controllers and to the Microsoft Entra service endpoints is essential.
• Time Synchronization: Accurate time synchronization across all domain controllers and the provisioning agent server is critical for Kerberos authentication.
• Required Permissions: The account used for installation must possess sufficient permissions to create gMSAs and make other necessary changes in Active Directory. Typically, this requires Domain Admin or Enterprise Admin privileges.
• Operating System Requirements: The server hosting the provisioning agent must meet the minimum operating system requirements specified by Microsoft, usually Windows Server 2016 or newer with all latest updates.
• PowerShell Version: An up-to-date PowerShell version is often required for executing administrative commands effectively.

Ensuring these foundational elements are in place before proceeding with the agent installation can significantly reduce the likelihood of encountering errors and streamline the deployment process.

Diagnosing the gMSA Creation Failure¶

A common and critical error encountered during the Cloud Provisioning Agent installation manifests as the following message:

“Unable to create gMSA because KDS may not be running on domain controller. Please create/run KDS manually.”

This error message is a direct indicator that the system is failing to provision the Group Managed Service Account (gMSA) required by the agent. The core issue, as suggested, often lies with the Key Distribution Service (KDS) on the domain controller, which is responsible for generating the keys necessary for gMSA operations. Without a properly functioning KDS, gMSAs cannot be securely created or managed, leading to the installation failure.

Investigating Event Logs for KDS and Kerberos Issues¶

When faced with the “Unable to create gMSA” error, the first step in diagnosis involves a thorough examination of the event logs. Specific Event IDs can provide critical clues about the underlying cause. Navigate to Applications and Services Logs > Microsoft > Windows > Security - Netlogon to look for EventIDs 9001 and 9002. These events often signal issues related to Kerberos or the Key Distribution Service.

While 9001 and 9002 are key indicators, it’s also prudent to check other relevant logs, such as the System and Directory Service logs, for any errors or warnings related to Active Directory replication, time synchronization (Event ID 36 in Time-Service log), or Kerberos authentication failures (Event ID 14 in System log). A systematic review of these logs provides a holistic view of the domain controller’s health and potential impediments to gMSA creation. Issues like delayed Active Directory replication could also cause problems, as the KDS Root Key needs to replicate across all domain controllers before gMSAs can be created reliably.

Understanding the Key Distribution Service (KDS) Root Key¶

The Key Distribution Service (KDS) plays a pivotal role in the creation and management of Group Managed Service Accounts (gMSAs). For gMSAs to function, a KDS Root Key must exist in the Active Directory forest. This root key is used to generate the necessary encryption keys for gMSAs, enabling their secure password management and Kerberos authentication. If the KDS Root Key is missing or has not replicated properly across all domain controllers, gMSA creation will fail.

You can verify the presence of the KDS Root Key by running the following PowerShell command on a domain controller:

Get-KdsRootKey

If no output is returned, it indicates that the KDS Root Key has not been created. It can be manually created using:

Add-KdsRootKey -EffectiveImmediately

It is essential to allow sufficient time (typically 10 hours for the EffectiveImmediately parameter to take full effect by default, though it can be configured) for the root key to replicate across all domain controllers in the forest before attempting gMSA creation again. Replication issues or time discrepancies can delay this process, leading to the very error we are troubleshooting.

Examining Kerberos Encryption Types¶

A common misconfiguration that can prevent gMSA creation, even with a healthy KDS, involves a mismatch in Kerberos encryption types. Modern security best practices advocate for stronger encryption standards, moving away from older, less secure types like RC4. The Microsoft Entra Connect Provisioning Agent’s gMSA may default to or require specific, stronger encryption types, while the domain controller or the gMSA object itself might be configured to disallow them or prefer weaker ones.

To ascertain the Kerberos encryption types supported by the server, execute the following command in an administrative command prompt:

C:\windows\system32>reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"

The output will include a SupportedEncryptionTypes DWORD value. For example, 0x7ffffff8 is a common value indicating support for AES128_HMAC_SHA1 and AES256_HMAC_SHA1. This hexadecimal value is a bitmask where each bit corresponds to a specific Kerberos encryption type. Understanding this value is crucial for diagnosing the issue.

Decoding 0x7ffffff8:
* 0x00000008 = RC4_HMAC_MD5
* 0x00000010 = AES128_HMAC_SHA1
* 0x00000020 = AES256_HMAC_SHA1
* 0x7ffffff8 is essentially a combination that excludes some deprecated types while including modern AES types. In simpler terms, it often indicates a preference for AES128 and AES256 over RC4.

This registry setting defines the server’s capability regarding Kerberos encryption. The next step is to examine the account’s capability.

Inspecting the msDS-SupportedEncryptionTypes Attribute¶

After determining the server’s supported encryption types, it’s essential to verify the msDS-SupportedEncryptionTypes attribute for the provAgentgMSA (or whatever the gMSA is named) within Active Directory Users and Computers (dsa.msc). This attribute dictates which Kerberos encryption types the specific service account is allowed to use.

Follow these steps to inspect the attribute:

1. Open Active Directory Users and Computers (dsa.msc).
2. Ensure that Advanced Features is enabled under the View menu.
3. Navigate to the Managed Service Accounts container or search for the provAgentgMSA directly.
4. Open the properties of the provAgentgMSA.
5. Select the Attribute Editor tab.
6. Locate and select the msDS-SupportedEncryptionTypes attribute, then click Edit.

Within the Attribute Editor, you’ll observe the current configuration for the gMSA. If this attribute contains a value that enables RC4 encryption (e.g., -2147483648 which corresponds to the Kerberos setting ‘Do not use Kerberos preauthentication’ but often is associated with older encryption types implicitly or explicitly) or if it lacks the modern AES types preferred by the server and the agent, a mismatch occurs. This discrepancy means the gMSA is attempting to use an encryption type that is either explicitly disallowed by the server or is not aligned with the server’s configured best practices, leading to the gMSA creation failure.

Identifying the Mismatch:
The core of the problem lies when the server, through its SupportedEncryptionTypes registry setting, is configured to primarily use modern AES encryption types (like AES128 and AES256), while the provAgentgMSA object in Active Directory still has RC4 enabled or doesn’t explicitly support the stronger AES types. This mismatch creates a security policy conflict: the server refuses to engage in Kerberos authentication with the gMSA using a deprecated encryption type, thereby preventing its successful creation or utilization. Removing RC4 from the account’s allowed encryption types ensures alignment with the server’s stronger security posture.

Resolution: Aligning Kerberos Encryption Types¶

The most effective way to resolve this issue is to ensure that the provAgentgMSA is configured to use modern, secure Kerberos encryption types, specifically AES128 and AES256, while explicitly removing support for RC4. This aligns the gMSA’s capabilities with the server’s security policy, allowing for successful Kerberos authentication and gMSA creation.

To modify the Kerberos encryption types for the provAgentgMSA, execute the following PowerShell command on a domain controller with appropriate administrative privileges:

Set-ADServiceAccount -Identity provAgentgMSA -KerberosEncryptionType AES128,AES256

This command updates the msDS-SupportedEncryptionTypes attribute for the provAgentgMSA, instructing it to exclusively use AES128 and AES256 encryption. By explicitly specifying these modern encryption types, you effectively disable support for RC4, which is often the source of the conflict. This change immediately strengthens the security posture of the gMSA and resolves the encryption type mismatch.

After successfully executing the command, it is crucial to perform the following steps:

1. Reboot the Provisioning Agent Server: A reboot ensures that all cached Kerberos tickets and service account properties are refreshed, allowing the server to recognize the updated encryption settings for the gMSA. This is a critical step for the changes to take full effect.
2. Reinstall the Provisioning Agent: With the gMSA’s encryption types correctly configured and the server rebooted, you can now proceed with the reinstallation of the Microsoft Entra Connect Provisioning Agent. The gMSA creation process should now complete without the previous error.

Comprehensive Troubleshooting Flow¶

For a more structured approach to diagnosing and resolving this issue, consider the following troubleshooting flow:

mermaid graph TD A[Start: Provisioning Agent Installation Fails] --> B{Error: "Unable to create gMSA, KDS may not be running"?}; B -- Yes --> C[Check KDS Root Key]; C --> D{Get-KdsRootKey shows output?}; D -- No --> E[Add-KdsRootKey -EffectiveImmediately]; E --> F[Wait 10+ hours for replication]; F --> G[Retry Agent Installation]; D -- Yes --> H[Check Event Logs for 9001/9002 (Netlogon)]; H --> I[Analyze Kerberos Encryption Types Mismatch]; I --> J[Run: reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"]; J --> K[Identify Server's SupportedEncryptionTypes (e.g., 0x7ffffff8 for AES)]; K --> L[Open ADUC, locate provAgentgMSA, check msDS-SupportedEncryptionTypes]; L --> M{Is RC4 enabled or AES missing from gMSA attribute?}; M -- Yes --> N[Execute: Set-ADServiceAccount -Identity provAgentgMSA -KerberosEncryptionType AES128,AES256]; N --> O[Reboot Provisioning Agent Server]; O --> P[Reinstall Provisioning Agent]; P --> Q[End: Issue Resolved]; B -- No --> R[Investigate other installation errors];

Best Practices and Preventative Measures¶

To avoid similar gMSA creation failures and maintain a healthy hybrid identity environment, several best practices should be adopted:

• Proactive KDS Root Key Management: Ensure the KDS Root Key is present and replicating correctly across your Active Directory forest. Periodically verify its status using Get-KdsRootKey.
• Consistent Kerberos Policy: Establish and enforce consistent Kerberos encryption policies across your domain controllers. Prioritize AES128 and AES256, and actively deprecate RC4 where possible to enhance security.
• Regular DC Health Checks: Conduct routine health checks on your domain controllers, paying close attention to Active Directory replication, time synchronization, and DNS resolution. These are foundational for Kerberos and gMSA operations.
• Security Baseline Adherence: Adhere to Microsoft’s security baselines and recommendations for Active Directory and Windows Server configurations to ensure optimal security and compatibility.
• Test Environment: Always test new configurations or agent installations in a non-production environment before deploying to production. This helps identify and mitigate potential issues without impacting live services.
• Detailed Documentation: Maintain thorough documentation of your Active Directory environment, including gMSA configurations, Kerberos policies, and any customizations.

By implementing these preventative measures, organizations can significantly reduce the likelihood of encountering gMSA creation failures and other related issues during Microsoft Entra Connect Provisioning Agent deployments. A well-maintained and securely configured Active Directory environment is the cornerstone of a reliable hybrid identity solution.

This troubleshooting guide provides a comprehensive approach to resolving gMSA creation failures during Microsoft Entra Connect Provisioning Agent installation, particularly those stemming from KDS issues and Kerberos encryption type mismatches. By understanding the underlying mechanisms and following the detailed resolution steps, administrators can swiftly overcome these challenges and ensure the successful deployment of their hybrid identity synchronization solution.

We Want to Hear From You!¶

Have you encountered similar issues during your Microsoft Entra Hybrid Sync deployments? Did this guide help you resolve the problem, or do you have additional insights or tips to share? Your experiences and feedback are invaluable to the community. Please feel free to share your thoughts, questions, or alternative solutions in the comments section below. Let’s learn and grow together!