Problem: Password Synchronization Failures with the UCS AD Connector After Microsoft Security Update KB5082063 (CVE-2026-20833)

Knowledge Base Community
, , , , , , , ,
1

Problem

After installation of the Microsoft security update KB5082063 (April 2026), authentication problems may occur in Windows Active Directory environments connected through the UCS AD Connctor.

After updating the affected Windows Domain Controllers to the April 2026 security update level or newer (May 2026 patch level), users synchronized through the AD Connector may no longer be able to authenticate against Active Directory.

A password change performed directly in UCS continues to work for authentication against UCS itself, but the synchronized UCS account cannot use the updated password in Active Directory.

Passwords changed in Active Directory can still be used in Active Directory and UCS without beeing affected by this issue.

Contents

Affected Environments

  • MS AD systems with a UCS AD Connector in sync (or write) mode

Fixed Version

The issue is related to Microsoft’s Kerberos hardening for CVE-2026-20833 and may affect environments running Windows Server 2025.

Root Cause

Microsoft introduced Kerberos hardening changes as part of the April 2026 cumulative update KB5082063.

According to Microsoft:

“[Kerberos protocol] This update changes the default DefaultDomainSupportedEncTypes value for Kerberos Key Distribution Center (KDC) operations to leverage AES-SHA1 for accounts that don’t have an explicit msDS-SupportedEncryptionTypes Active Directory attribute defined.”

The April 2026 update changes the default KDC behavior from allowing RC4 encryption to AES-only operation.

April 14, 2026 – Enforcement Phase with Manual Rollback

Microsoft changed the default value of the registry setting DefaultDomainSupportedEncTypes from 0x27 to 0x18 which disables the use of RC4 hashes and allows only AES encryption types by default.

Accounts that do not have the attribute

msDS-SupportedEncryptionTypes

explicitly configured are longer able to be authenticated against RC4 hashes.

This issue is tracked in the following Univention bug reports:

Erratum 462 introduced setting the attribute:

msDS-SupportedEncryptionTypes

during UCS → AD password synchronization to enable the use of RC4 hashes (by adding the bit 0x4).

Existing accounts only receive the attribute after a password change occurs on the UCS side.
The bit is subtracted again by the AD-Connector if password changes are found in Microsoft Active Directory to keep the security baseline as high as possible.

See also this section of the UCS manual for an explanation.

Investigation

What is CVE-2026-20833?

CVE-2026-20833 (“Windows Kerberos Information Disclosure Vulnerability”) addresses the continued use of the weak RC4 encryption type in Kerberos environments.

An authenticated attacker may obtain Kerberos service tickets encrypted with RC4 and perform offline password recovery attacks against service accounts.

To mitigate this risk, Microsoft is moving Active Directory environments toward AES-only Kerberos encryption.

Kerberos RC4 Hardening Phases

Phase 1 – Auditing (January 2026)

Starting with the January 2026 updates:

  • The registry key RC4DefaultDisablementPhase can be created.
  • Setting the value to 1 enables new auditing events (201–209) on Domain Controllers.
  • The KDC continues issuing RC4 tickets.

No functional changes are introduced during this phase.

Phase 2 – Soft Enforcement (April 2026)

The KDC rejects requests that support only RC4 unless RC4 has been explicitly enabled before installing the update.

Changes include:

  • RC4DefaultDisablementPhase is automatically set to 2
  • The value can still be reverted to 1
  • If DefaultDomainSupportedEncTypes was not previously configured, Microsoft automatically sets:
0x18

(AES only)

Administrators can manually change the value to:

0x1C
0x24
0x3C

to re-enable RC4 support.

Phase 3 – Hard Enforcement (July 2026)

In this phase:

  • RC4DefaultDisablementPhase is ignored completely.
  • Automatic RC4 fallback is removed.

RC4 can only be enabled by:

  • Explicitly setting msDS-SupportedEncryptionTypes on accounts
  • Configuring Kerberos encryption types via Group Policy
  • Configuring DefaultDomainSupportedEncTypes globally

This phase does not remove RC4 entirely, but removes the ability to use RC4 by default.

Relation to UCS Erratum 462

Erratum 462 introduced support in the AD Connector to populate:

msDS-SupportedEncryptionTypes

during password synchronization from UCS to Active Directory.

This ensures affected accounts can continue using RC4 when required.

However, the attribute is only written after a password change occurs.

Therefore, existing accounts may still be affected until passwords are changed or the attribute is otherwise populated.

Workaround

The following workaround globally re-enables RC4 support on the Windows Domain Controller.

Important

This workaround is intended as a temporary mitigation until all affected accounts have the required Kerberos encryption attributes configured.

Step 1: Configure DefaultDomainSupportedEncTypes

Create the following registry value.

Windows Server 2016 / 2019 / 2022

Registry path:

HKLM\System\CurrentControlSet\Services\KDC

Windows Server 2025

Registry path:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Create a new value:

Name: DefaultDomainSupportedEncTypes
Type: REG_DWORD
Value: 0x1C

Value 0x1C enables:

  • RC4-HMAC
  • AES128-CTS-HMAC-SHA1-96
  • AES256-CTS-HMAC-SHA1-96

Step 2: Restart the KDC Service

Apply the new configuration by restarting the KDC service.

PowerShell

Restart-Service Kdc

Alternatively reboot the Domain Controller.

Result

After the KDC service restart, users can again authenticate using passwords synchronized through the UCS AD Connector.

Solutions

Solution 1: Force Password Changes

A permanent solution is to trigger a password change for all affected user accounts.

After the password change:

msDS-SupportedEncryptionTypes

is populated automatically by the AD Connector as implemented in Erratum 462.

As a result, the account can continue using RC4 where required.

Solution 2: Configure Kerberos Encryption Types via Group Policy

Another option is to configure Kerberos encryption support centrally using Group Policy.

The following security setting populates the Kerberos encryption configuration on Domain Controllers:

Computer Configuration
 └─ Policies
     └─ Windows Settings
         └─ Security Settings
             └─ Local Policies
                 └─ Security Options
                     └─ Network security:
                        Configure encryption types allowed for Kerberos

Recommended Values

RC4-Compatible Configuration

0x7FFFFFFC

Supported encryption types:

RC4-HMAC
AES128-CTS-HMAC-SHA1-96
AES256-CTS-HMAC-SHA1-96
AES256-CTS-HMAC-SHA1-96-SK
FAST-supported
Compound-identity-supported
Claims-supported
Resource-SID-compression-disabled
Future encryption types

Supported encryption types:

AES128-CTS-HMAC-SHA1-96
AES256-CTS-HMAC-SHA1-96
AES256-CTS-HMAC-SHA1-96-SK
FAST-supported
Compound-identity-supported
Claims-supported
Resource-SID-compression-disabled
Future encryption types

Result

After applying the Group Policy and rebooting affected systems, authentication using synchronized user accounts should work again.

References