Op 14 juli 2026 verwijdert Microsoft de laatste terugvaloptie voor RC4 in Kerberos. Wie na de Patch Tuesday-update nog service accounts of legacy apparaten heeft die op RC4 vertrouwen, loopt authenticatiefouten op. Wat verandert er, welke systemen zijn kwetsbaar en welke stappen zet u deze week nog?
RC4 is al meer dan tien jaar cryptografisch verouderd. Toch draait het nog steeds in de achtergrond van veel Active Directory-omgevingen, verstopt in service accounts die al jaren niet zijn aangepast, in printers die uitsluitend RC4-Kerberos-tickets accepteren, of in applicaties waarvan de vendor de encryptie nooit heeft bijgewerkt. Op 14 juli 2026 haalt Microsoft de laatste noodrem weg: na die datum bestaat de mogelijkheid om terug te vallen op auditmodus niet meer.
Dit is geen zachte aankondiging. Het is het eindpunt van een proces dat Microsoft in januari 2026 heeft ingezet met CVE-2026-20833 en dat nu de finale fase ingaat. IT-teams die deze update installeren zonder voorbereiding, kunnen authenticatiefouten verwachten op systemen die nog afhankelijk zijn van het zwakke RC4-HMAC-algoritme.
Microsoft heeft de RC4-afschaffing in Kerberos stapsgewijs doorgevoerd. In de eerste fase, vanaf 13 januari 2026, werden auditevenementen geactiveerd. Domain controllers logden waarschuwingen telkens als een service-ticket met RC4 werd aangevraagd. IT-teams kregen zo zichtbaarheid in het RC4-gebruik zonder dat er al iets brak.
In de tweede fase, met de april 2026-updates, begon de daadwerkelijke handhaving. Domain controllers gingen standaard over op AES-SHA1 voor accounts waarop het msDS-SupportedEncryptionTypes-attribuut leeg of ongedefinieerd was. Via de registersleutel RC4DefaultDisablementPhase konden beheerders tijdelijk terugschakelen naar auditmodus als een omgeving nog niet klaar was. Die veiligheidsklep verdwijnt op 14 juli.
Na de juli 2026-update bestaat RC4DefaultDisablementPhase niet meer als werkend mechanisme. Enforcement is permanent. RC4 werkt uitsluitend nog als het expliciet is geconfigureerd op het betrokken account of op de KDC zelf.
RC4 in Kerberos is niet alleen verouderd, het is een concrete aanvalsvector. Aanvallers die toegang hebben tot het netwerk kunnen Kerberos-servicetickets opvragen die zijn versleuteld met RC4, het zogenoemde Kerberoasting. Omdat RC4-HMAC cryptografisch zwak is, kunnen deze tickets offline worden gekraakt met relatief bescheiden rekenkracht. Een service account met een zwak wachtwoord dat RC4-tickets uitgeeft, kan binnen uren worden gecompromitteerd.
Accounts die worden gekraakt via Kerberoasting worden vervolgens ingezet voor laterale beweging door het netwerk, privilege escalation of ransomware-implementatie. Voor aanvallers is een omgeving die nog RC4 toestaat een welkom cadeau. De hardening die Microsoft doorvoert, sluit deze aanvalsvector structureel.
De meeste impact hebben service accounts waarvan het msDS-SupportedEncryptionTypes-attribuut leeg is of uitsluitend RC4 bevat. Als er geen expliciete waarde is ingesteld, bepaalt de KDC de toegestane encryptietypes op basis van de domeinpolicy. Na de april-update is de standaardwaarde 0x18, wat AES128 en AES256 betekent. Accounts die alleen RC4 ondersteunen maar geen AES-sleutels hebben aangemaakt, kunnen geen geldige tickets meer ontvangen.
Naast service accounts zijn oudere printers, scanners, NAS-apparaten en embedded systemen kwetsbaar. Apparaten die uitsluitend RC4-Kerberos-tickets begrijpen en waarvan de firmware al jaren niet is bijgewerkt, zullen authenticatieproblemen ondervinden. Hetzelfde geldt voor sommige Linux-systemen en applicaties van derde partijen die gebruik maken van niet-Windows Kerberos-implementaties zonder AES-ondersteuning.
Opmerkelijk is ook SQL Server, dat op bepaalde configuraties nog RC4 gebruikt voor Kerberos-authenticatie richting de database engine. Omgevingen die SQL Server via Kerberos laten authenticeren, moeten dat expliciet controleren.
Zolang de juli-update niet is geïnstalleerd, kunt u RC4-gebruik nog waarnemen via de Windows Security-logboeken. Zoek op Event ID 4769, de Kerberos Service Ticket Operations. In de details van dit event staat het veld Ticket Encryption Type. De waarde 0x17 correspondeert met RC4-HMAC. Elke 4769-log met die waarde is een systeem of account dat na 14 juli problemen kan krijgen.
Domain controllers loggen ook specifieke Kdcsvc-systeemevenementen, te herkennen als Event ID 202 en 207. Deze worden aangemaakt op het moment dat een RC4-ticketaanvraag wordt verwerkt voor een account dat geen expliciete AES-configuratie heeft. Een zoekopdracht over alle domain controllers op die event-ID's geeft een directe lijst van kwetsbare accounts.
Microsoft heeft de detectiestappen gepubliceerd op Microsoft Learn onder 'Detect and Remediate RC4 Usage in Kerberos'. De paginanaam is voldoende om de juiste documentatie te vinden via een zoekopdracht in de Microsoft Learn-bibliotheek.
De remediation bestaat uit twee stappen per getroffen account. Ten eerste moeten de Kerberos-sleutels worden vernieuwd zodat het account AES-sleutels heeft in Active Directory. Dit doet u door het wachtwoord van het service account te resetten, wat automatisch nieuwe Kerberos-sleutels aanmaakt inclusief AES128 en AES256. Vervolgens stelt u het msDS-SupportedEncryptionTypes-attribuut expliciet in op 0x18 (AES128 + AES256) via ADSI Edit, PowerShell of uw Active Directory-beheertool.
De PowerShell-opdracht om het attribuut in te stellen is: Set-ADUser -Identity 'accountnaam' -KerberosEncryptionType 'AES128,AES256'. Voor computer accounts geldt Set-ADComputer met dezelfde parameter. Voor service accounts die worden beheerd via gMSA (Group Managed Service Accounts) verloopt de sleutelvernieuwing automatisch, omdat gMSA-wachtwoorden periodiek worden geroteerd.
Let op dat een wachtwoordreset voor productie service accounts altijd gecoördineerd moet worden met de applicatieteams. Services die met het account zijn geconfigureerd moeten worden bijgewerkt met het nieuwe wachtwoord of de nieuwe serviceidentiteit. Plan dit buiten productieuren.
Voor apparaten en applicaties die technisch gezien geen AES-Kerberos ondersteunen en waarvoor geen firmware- of software-update beschikbaar is, biedt Microsoft een tijdelijke uitweg: het msDS-SupportedEncryptionTypes-attribuut instellen op 0x24. Deze waarde combineert AES met RC4 voor sessie-sleutels, wat sommige oudere implementaties nodig hebben om te kunnen functioneren. Dit is geen gewenste situatie, maar voorkomt dat productiesystemen in een onherstelbare fout belanden.
Wees u bewust van de implicaties: een account met expliciet toegestaan RC4 is een zwakker account vanuit aanvalsperspectief. Zorg dat zulke accounts worden gemonitord, dat hun wachtwoorden lang en complex zijn, en dat ze zijn opgenomen in uw inventaris voor toekomstige migratie zodra de leverancier een AES-update uitbrengt.
Met Patch Tuesday op 14 juli zijn er nog vijf werkdagen. Drie concrete acties die IT-teams nu prioriteit moeten geven. Ten eerste, run de Event ID 4769-query over de security logs van alle domain controllers voor de periode van de laatste dertig dagen en exporteer alle accounts met Ticket Encryption Type 0x17. Ten tweede, controleer van elk gevonden account de msDS-SupportedEncryptionTypes-waarde en reset het wachtwoord als er geen AES-sleutels zijn. Ten derde, maak een lijst van legacy apparaten die mogelijk RC4 vereisen en configureer hun service accounts met waarde 0x24 als tijdelijke maatregel.
Het installeren van de juli-update zonder deze controles achter de rug te hebben, is het risico niet waard. Een authenticatiefout op een kritiek systeem midden in een werkdag kost meer tijd dan een preventieve check nu. Organisaties die ondersteuning willen bij het uitvoeren van de RC4-audit of het remediëren van service accounts, kunnen contact opnemen met Zarioh.
Was dit artikel nuttig?
Zarioh Digital Solutions
IT-specialisten uit Utrecht. Wij helpen bedrijven door heel Nederland met Microsoft 365, AI agents, hosting en telefonie — en delen hier wekelijks wat we in de praktijk tegenkomen. Volg ons op LinkedIn
Ontvang nieuwe artikelen direct in je inbox.
Geen spam. Afmelden kan altijd.
Security
Security
Security
