Open-E JovianDSS and the Microsoft Kerberos RC4 deprecation (CVE-2026-20833)
Article ID: 3572
Last updated: 18 Jun, 2026
Additional information:
product name: JovianDSS
product version: all
build: all
Subject: Whether an Active Directory-integrated JovianDSS (single-node or HA cluster, joined in member mode) is affected by Microsoft's Kerberos RC4 deprecation (CVE-2026-20833), and whether any appliance change or Software Update is required.
Summary
Microsoft is phasing out the RC4 encryption type in Kerberos and will, by the second quarter of 2026, change the Active Directory KDC default to AES. The hardening is tracked under CVE-2026-20833. Customers running an AD-integrated JovianDSS appliance have asked whether AES must be "forced" on the appliance and whether a Software Update (SU) is needed.
Short answer: no.CVE-2026-20833 is a Microsoft Windows / Active Directory vulnerability, not a JovianDSS vulnerability, and there is no JovianDSS code to patch. Every supported JovianDSS release already supports AES Kerberos and advertises it first. Once Active Directory stops offering RC4, the appliance negotiates AES automatically, with no reconfiguration and no downtime. Enforcing AES is an Active Directory (domain controller) task, not an appliance task.
1. What CVE-2026-20833 changes
CVE-2026-20833 is an information-disclosure weakness in Windows Kerberos (Microsoft rates it CVSS 5.5 Medium, CWE-327, use of a broken or risky cryptographic algorithm). It concerns service tickets issued with the legacy RC4 cipher: such tickets can be captured and cracked offline (the "Kerberoasting" technique) to recover a service-account password. To address it, Microsoft is removing RC4 as an assumed-supported encryption type and moving the KDC default to AES (AES-SHA1).
Microsoft is rolling the change out in phases. The dates below come from Microsoft's own guidance (see Related articles); confirm the current schedule with Microsoft, as Microsoft may adjust it.
Phase
Date
What changes on the domain controllers
Audit / warning
January 13, 2026
DCs emit audit events (4768 / 4769) flagging accounts that still rely on RC4. A registry control (RC4DefaultDisablementPhase) is introduced.
Default hardening
April 14, 2026
The KDC default (DefaultDomainSupportedEncTypes) changes to AES-SHA1. Administrators can still roll back manually via the registry.
Final enforcement
July 2026 (and later updates)
The rollback registry subkey is removed. RC4 stays disabled unless explicitly re-enabled per service.
The replacement encryption is AES: AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96.
2. How an AD-integrated JovianDSS is affected
A JovianDSS appliance joined to Active Directory acts as a Samba AD member server, not as a domain controller. It is a Kerberos client of your DCs.
At join time, the appliance writes AES128 and AES256 keys into its local machine keytab (one keytab per node on an HA cluster), and Samba advertises AES first in every Kerberos request (AS-REQ / TGS-REQ).
AES support is built into every currently supported JovianDSS release. It is not a per-system setting and it is not version-gated.
The Kerberos session-key encryption type is chosen by the KDC (your domain controller) from the intersection of: what the client offers, the msDS-SupportedEncryptionTypes attribute on the appliance's computer object, and the KDC policy. The appliance is never the limiter for AES, the Active Directory side is the gate.
Therefore, when your domain controllers stop offering RC4, the appliance simply receives AES session keys instead. There is nothing to change on the appliance, and no Software Update is required for this, an OS update would change nothing about this behavior.
3. Enforcing AES is an Active Directory task
There is nothing to configure on JovianDSS. AES is enforced on the domain-controller (KDC) side of Active Directory, by your AD administrator. For the exact, current procedure, follow Microsoft's own guidance (see Related articles). Microsoft owns this configuration and may change the recommended steps over time, so we do not reproduce them here.
What matters from the JovianDSS perspective:
No appliance action is required. When the KDC stops issuing RC4, the appliance receives AES session keys automatically. winbind on the appliance renews its machine ticket every few hours (worst case about 10 hours), and any new SMB client logon triggers a fresh Kerberos exchange, so the change is picked up on its own, with no reboot and no re-join.
Enforce AES at the domain-controller level, not on the appliance's individual computer account. See section 4 for why the per-computer attribute does not stick on a JovianDSS member.
4. What NOT to do
Do not set msDS-SupportedEncryptionTypes = 24 (AES only) on the appliance's computer account and then re-join the domain to "lock in" AES.
A JovianDSS domain join (net ads join, the operation behind the GUI Join action) writes msDS-SupportedEncryptionTypes on the computer object at join time, with the value 31 (0x1F, which still includes RC4). This overrides any value an AD administrator set by hand. So setting 24 and then re-joining is self-defeating, the re-join reverts the attribute back to 31 and RC4 remains permitted.
Enforce AES at the domain-controller (KDC) level (section 3) instead. That gate is independent of the per-computer attribute and is not undone by a re-join.
There is also no customer-editable Kerberos encryption setting on the appliance: the Samba kerberos encryption types option and /etc/krb5.conf live in appliance-managed system layers that are regenerated on join and on update. JovianDSS is a closed appliance, and for this scenario it needs no such change.
5. How to verify
The appliance needs no verification step of its own, and it produces no RC4-related log signature. Verification is done on the Active Directory side, by your AD administrator, from the appliance's computer-account Kerberos logon events on the domain controller.
After AES enforcement takes effect and winbind renews (or after the next SMB logon), the session key type for those events should read:
instead of the legacy 0x17 (RC4-HMAC). No appliance reboot is needed. For how to read these events, see Microsoft's guidance in Related articles.
6. Frequently asked questions
Q: Do we need a Software Update (SU) or a JovianDSS version upgrade for the RC4 deprecation? A: No. AES Kerberos is built into every supported release. An SU or OS upgrade changes nothing about which session-key type the KDC issues.
Q: Can we "force AES" inside the JovianDSS GUI or console? A: There is no such setting, and none is needed. The appliance already offers AES first. Enforcement belongs on the Active Directory side (section 3).
Q: Will our HA cluster behave any differently? A: No. Each node is an independent AD member with its own machine keytab and behaves identically. The storage topology (Shared-Storage HA or Metro/Non-Shared HA) is irrelevant to Kerberos enctype selection.
Q: After Microsoft disables RC4, will SMB/AD access from the appliance break? A: No. Because the appliance already holds AES keys, the switch to AES session keys is transparent. Access continues without interruption.
