[EN]Die zum 14. April 2024 für Windows veröffentlichten kumulativen Sicherheitsupdates verursachen einige Probleme. Mir liegen einige Nutzerberichte vor, dass eine Benutzeranmeldung nach Installation der April 2026-Updates nicht mehr möglich ist. Betrifft Windows Server, aber mutmaßlich auch Windows 11-Clients (wobei das ein anderer Fehler sein kann).
Windows Updates April 2026
Zum 14. April 2026 hat Microsoft kumulative Sicherheitsupdates für die noch unterstützen Windows-Clients und Windows-Server-Versionen freigegeben. Ich hatte im Blog-Beitrag Patchday: Windows 10/11 Updates (14. April 2026) sowie im Beitrag Patchday: Windows Server-Updates (14. April 2026) darüber berichtet.
Bei einigen Systemen gab es Fehler bei der Update-Installation, die ich im Blog-Beitrag Windows Server 2025: Update KB5082063 liefert Error 0x800F0983, 0x80073712 sowie im Beitrag Windows Server 2025: Fehler 0x80073712 bei KB5082063 durch Media Player-Sprachpakete hier im Blog angesprochen habe. Aber es gibt ein weiteres Problem, das eine Benutzeranmeldung verhindert. Und es ist kein Einzelfall.
Meldungen zu Anmeldeproblemen
Aber es gibt ein weiteres Problem, das eine Benutzeranmeldung verhindert. Und es ist kein Einzelfall.
Eine Leser-Mail mit einer Nachfrage
Zum gestrigen 17. April 2026 hat sich Blog-Leser Toni K. per E-Mail gemeldet und berichtete unter dem Betreff "Windows Server 2025 DC Probleme nach KB5082063" von Anmeldeproblemen. Er habe "die Tage, nach der Installation des KB5082063, Probleme auf Server 2025 DCE als AD feststellen müssen" meinte er.
- Der erste Fall war ein Kunde, der sich plötzlich nicht mehr mit dem Administrator -Konto auf dem (NetScaler) ADC oder eine anderen, mit dem Active Directory (AD) verbundenen System anmelden konnte. Es kam der Hinweis dass das Passwort oder der Benutzername nicht passen würde. Nach dem Neu setzten des Passworts (utilman.exe…) war das Problem gelöst. Der Leser schrieb, dass keine Hinweise auf einen Sicherheitsvorfall gefunden werden. konnten.
- Der zweite Fall trat am 16. April 2026 beim Blog-Leser selbst auf. Er hatte plötzlich das gleiche Problem auf einem anderen Windows Server 2025 DCE mit ADC-Rolle.
Die Gemeinsamkeit bestand laut Blog-Leser darin, dass beide Systeme sich zuvor das Update KB5082063 gezogen und installiert hatten. Nach einer Online-Recherche, merkt der Nutzer an, dass er nur einen Post bei Reddit mit dem gleichen Problem und Verweis auf das Update gefunden habe (siehe folgende Abschnitte). Der Leser fragte: "Haben Sie dazu auch Meldungen bekommen?"
Lesermeldung zu Anmeldeproblemen bei Windows Server 2025
Bei mir klingelte direkt ein "da war doch was" im Hinterkopf. Eine kurze Suche brachte diesen Kommentar von Blog-Leser Rmg, der schrieb: "Hurra, nach der Installation auf zwei Windows Server 2025 kann ich mich nicht mehr einloggen. Das Passwort wird nicht mehr akzeptiert. Bin mal gespannt ob ich das ohne Rollback wieder hinbekomme…". Später ergänzte der Leser "Nach Passwortänderung geht es wieder, für die User habe ich jetzt eine erzwungen."
Ein Thread auf reddit.com
Blog-Leser Toni K. hat mir auf Nachfrage dann den Link auf den reddit.com-Thread Ransomware attack, now can't log in as the default domain administrator account, but can with other DA accounts. geschickt. Der Titel suggeriert etwas anderes, aber ein Folgekommentar im Thread beschreibt genau obiges Fehlerbild:
Hello, I'm expecting the same behavior in one of my networks. The user Administartor cannot log in throught the Remote Desktop or interactively on one of the Domain Controllers running Windows Server 2025 Datacenter. It started after KB5082063 Security Update from April 2026. If I remove the update, the Administrator can log in without any Problem. The other Domain Controller running Windows Server 2022 Datacenter is not affected. I found only in Security log Events 4624 and 4634.
I can also see Event 1149 in Remote Desktop Event log:
Remote Desktop Services: User authentication succeeded: User: Administrator Domain: MYDOMAIN
In diesem Thread bestätigen weitere Betroffene dieses Fehlerbild unter Windows Server 2025 in Verbindung mit dem April 2026-Update KB5082063. Reset des Passworts oder die Deinstallation des Update KB5082063 hat das Problem behoben.
Anmerkung: Bei heise habe ich in diesem Beitrag ebenfalls einen vagen Hinweis gefunden, dass es möglicherweise Anmeldeprobleme bei Windows Server 2025 DCs gebe. In diesem Kommentarthread gibt es dann Einträge Betroffener.
Möglicherweise RC4-Abschaltung als Problem
Leser vermuteten, dass die Anmeldeprobleme mit der RC4-Abschaltung durch das April 2026 Update verursacht werden könnte. Blog-Leser rmg schrieb dazu in diesem Kommentar, dass es sich um Systeme handele, deren AD-Struktur über mehrere Servergenerationen weitervererbt wurde. Nach einer Änderung des Passworts funktioniert es wieder. Er hat diese Passwort-Änderung für die Benutzer im AD erzwungen. Das dürfte die einzige Lösung in größeren AD-Umgebungen, wo viele Nutzer betroffen sind, sein.
Leser ChristopH merkt in diesem Kommentar an: "Wenn die Domäne mit Windows Server 2003 erstellt wurde sind alle Passworte die seither nie geändert wurden noch mit RC4 verschlüsselt. Mit dem Upgrade der DC auf Server 2012 R2 wurden dann neue oder geänderte Passworte mit AES verschlüsselt, wenn da für das Benutzerkonto im AD nichts anderes eingestellt wurde. Wenn ich mich richtig erinnere, haben wir dann einfach alle Passworte mit einem Änderungsdatum älter als das Upgrade-Datum der Domäne von 2003 auf 2012 geändert und gut war. Alle anderen mussten wir nicht anfassen." ChristopH merkt an, dass der Beitrag Kerberos RC4 Abschaltung von Frank Carius bezüglich des Themas RC4-Abschaltung eine sehr gute Quelle sei.
In diesem Kommentar merkt Leser Markus S. allerdings an, dass er sich inzwischen nicht mehr so sicher sei, dass da nicht doch noch ein anderes Problem besteht. Einer seiner Administratoren berichtete, dass in einer neu eingerichteten Laborumgebung mit Microsoft Windows Server 2025 dasselbe Problem aufgetreten ist. RC4-Altlasten konnten das in diesem Szenarieo nicht gewesen sein, weil die Umgebung nur aus einem DC und drei Mitgliedsservern besteht, die alle im Dezember 2025 völlig neu und auf neuer Hardware installiert wurden. Sie haben auch keine Verbindung zu einer bestehenden Domänenstruktur außerhalb ihrer eigenen.
Passwort über net /user ändern
Patrick schrieb hier: Wenn ein Server oder PC noch mit dem AD Account angemeldet ist dort mit Cmd das Kennwort ändern.
net user /domain administrator Test123
Dadurch setzt man den neuen AES-256 Verschlüsselungstyp und man kann sich wieder anmelden.
Anmeldeprobleme bei Windows 11
Weiterhin meldete sich eine Anwenderin in diesem Kommentar und berichtete, dass das Update KB5079473 vom 11.03.2026 hatte ihr mir zu Anmeldeproblemen an einem Notebook geführt habe. Nach Eingabe des Kennwortes schaltete sich das Gerät ab. Das Fehlerbild ist aber anders als in obigem Szenario.
Ein weiterer Blog-Leser bestätigt in diesem Kommentar: "Bei mir ein ähnliches Verhalten, 04/2026 update -> zack Bitlocker Recovery-Key [wird angefordert], und dann schaltet sich der Laptop einfach so beim Anmelden ab und das schon zweimal. Das Blöde daran, der Laptop befindet sich leider jetzt an einem Remote Standort und niemand ist vor Ort." Passt. Und in diesem Kommentar bei heise ist etwas ähnliches beschrieben.
Ergänzung: Blog-Leser Mario H. hat sich zum 19. April 2026 per E-Mail gemeldet und schrieb. dass der obige Beitrag interessant sei und er kann folgendes Verhalten bestätigen könne:
Vier mobile Windows 11 Systeme (2x Surface Laptop, 2x Terra Laptop), alle an einem Remote-Standort außerhalb der Domäne, konnten sich nach der Installation der April 2026 Updates nicht direkt an der Anmeldemaske von Windows anmelden. STRG-ALT-ENTF führte nur zu einem blauen Bildschirm ohne Anmeldemaske. Nach einer Wartezeit von 1-2 ½ Stunden konnten sich die betroffenen Benutzer problemlos wieder anmelden.
Die IT sei gerade dabei, dieses Phänomen zu untersuchen. Einen Hardwaredefekt könne man definitiv ausschließen. Auffällig sei, dass 3 der 4 Benutzer keine oder eine schlechte Internetverbindung hatten. Alle Geräte, die am Standort der Domäne die Updates durchgeführt hatten, waren von diesem Problem nicht betroffen.
Ähnliche Artikel:
Microsoft Security Update Summary (14. April 2026)
Patchday: Windows 10/11 Updates (14. April 2026)
Patchday: Windows Server-Updates (14. April 2026)
Patchday: Microsoft Office Updates (14. April 2026)
Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung
Windows 11 April 2026-Updates (KB5083769, KB5082052) triggern BitLocker Recovery
Windows Server 2025: Update KB5082063 liefert Error 0x800F0983, 0x80073712
Windows Server 2025: Fehler 0x80073712 bei KB5082063 durch Media Player-Sprachpakete
Windows Server 2016-2025: Reboot von Domain Controllern durch April 2026-Update (KB5082063 etc.)
MVP: 2013 – 2016
Vielleicht vor der Installation zuerst mal mit den beiden Skripten von MS die RC4-Nutzung testen?
RC4-Verwendung überwachen
Das dachte ich mir gerade auch. Microsoft hat es lange angekündigt und immer wieder gewarnt. Wir haben bei uns alles genau geprüft und geändert seit Januar 2026.
Ehrlich gesagt: Es ist schon schwierig… Auf der einen Seite wird Microsoft kritisiert, dass sie den unsicheren Legacy-Mist nicht endlich per Default zu machen, auf der anderen Seite müssen aber auch wir AdministratorInnen hier tätig werden und unsere Arbeit ordentlich machen.
100%. Wenn man einfach nur Cumulative Updates einspielt und keinerlei groß angekündigte und überall verbreitete Neuigkeiten erfasst, darf man sich nicht wundern, wenn das eine oder andere "Erlebnis" lauert.
Ich persönlich meckere auch nicht – als jemand, der diese ganze "Microsoft Timebombs" Kultur mit seinen verschiedenen Schaltphasen mittlerweile gewohnt ist und sieht, was bei anderen Plattformen und Produkten so im Alltag los ist, da gibts auch nicht alles als Selbstläufer.
Auf der anderen Seite konzipiert und verkauft MS seine Produkte schon immer so, dass sie von jeder Pappnase irgendwie zum laufen zu bekommen sein sollen.
Dazu könnte man noch einen optional zuschaltbaren "Windows-Update-Pappnasen-Channel" erfinden, der bei Sachen wie dieser rechtzeitig Readyness Tools mit Warnschildern voraus laufen lässt.
(Wenns um Marketing und Produkterneuerungen geht, erfinden die schließlich auch die tollsten Informationskanäle…)
So richtig gut nachvollziehbar ist das Ganze dort aber auch nicht gestaltet. Ich erhalte z. B. von der List-AccountKeys.ps1 eine Liste von Account, in denen als Keys jeweils "AES128-SHA96; AES256-SHA96; RC4" angegeben ist. Wie man jene Liste nun aber korrekt interpretiert? Ich hatte angenommen, durch das Vorhandensein der AES-Einträge ist alles OK. Oder spricht allein das Vorhandensein des RC4 für ein Problem? Je nach Internet-Quelle scheint beides zu stimmen. :-/
Hauptsächlich kontrolliert habe ich daher bei uns mit "Get-KerbEncryptionUsage.ps1 -Encryption RC4" – was keinen Output generierte. Allerdings durchsucht dieses Script ja auch nur das Ereignisprotokoll, besteht also latent die Gefahr, dass selten benutzte Konten dennoch betroffen sind?
Sorry, wenn ich mich an der Stelle als begriffsstutzig erweise, aber eine simple step-by-step-Anleitung wäre hilfreich gewesen, für all jene, die sich im täglichen Geschäft nicht so tief in die Materie einarbeiten. Die Kommunikation seitens MS empfinde ich hier ähnlich umständlich und verwirrend wie beim Thema "SecureBoot Updates".
Weiterhin wirft die ganze Sache Fragen auf. Ich habe die Scripts auf einer Reihe von Umgebungen laufen lassen, und es wurden teilweise RC4-only-Konten gefunden, die DEFINITIV keine Win2003-Altlast sind. Die fraglichen Systeme wurden seinerzeit mit Server 2012R2 neu aufgesetzt und in den Folgejahren bis Server 2016/2019 aktualisiert. Nach offizieller Lesart hätte doch aber auch 2012 schon AES verwenden müssen?
Hallo, hier kann ich Nordnavigator nur voll und ganz zustimmen. Schon alleine das Vorgehen einfach nur das eventlog auszuwerten, was vielleicht mal gerade 1-2 Monate alt ist, ist doch vom Ansatz her wenigstens fragwürdig. Was ist mit den Geräten / Konten die sich nur sehr selten anmelden? Auch wir haben ListAccountKeys bei zig Kunden ausgeführt und rätseln nun herum was die Ausgabe pro Konto denn nun genau bedeuten soll. Darf hier RC4 überhaupt noch auftauchen? Was mache ich wenn RC4 zusammen mit AES erscheint? Besteht hier Handlungsbedarf bei diesem Konto?
Wir haben daher prophylaktisch alle administrativen Konten mit neuen Passworten versehen, damit wir bei Problemen überhaupt noch andere Konten zurücksetzen können.
Grüße Jörg
Think there is bit misunderstood (and MS is responsible for that).
You can use, even after jun/jul updates, RC4. But, RC4 not been used "by default" (which is MS standard – worst algoritm first). You must specify accounts (ie with msDS-SupportedEncryptionTypes) with RC4 only. And DC will (it's main change) respect this.
With 2k25 it's another problem, with sha256. MS change worst-first to best-first, but only 2k25 know sha256. So maybe problems with admin logins are about DC want sha256, but user have sha1.
Btw: https://github.com/MichaelGrafnetter/DSInternals/blob/master/Documentation/PowerShell/Get-ADReplAccount.md
For aes checking (as admin on dc), not need date or time domain level upgrade etc … you can really see per account if have or not aes.
And don't forget to change the password twice for those who only have rc4.
Wenn sich jemand von extern per Citrix mit einem seit ca. 20 Jahren nicht geänderten RC4-Passwort, wahrscheinlich auch noch ohne 2FA, von extern anmeldet, dem ist nicht zu helfen.
dochdoch, durch eine passwortzurücksetzung :)
One in a Million Fälle…..
„Ein Leser hat sich gemeldet „ ….
Der kleine Fehlerteufel hat sich zu Beginn des Artikels eingeschleußt:
Die zum 14. April 2024 …
betrifft auch den Artikel: https://borncity.com/blog/2026/04/19/ungewollte-windows-server-upgrades-2019-und-2022-auf-2025/
Moin,
ich habe seit gestern auch ein komische Phänomen mit einem User. Sein Passwort ist erst vom 27.11.2025, also nicht wirklich alt. Unsere Domäne ist auf 2016er Stand mit 2019ern Servern.
Seit gestern bekam er plötzlich Mittags beim entsperren seines Rechners die Meldung, Passwort sei falsch. Vormittags gings noch. Auf dem DC seh ich auch geloggte Falscheingaben. Heute morgen konnte er sich ganz normal wieder mit dem Passwort anmelden. Jetzt gerade war es wieder als Falsch angemeckert.
Ich lass ihn jetzt mal sein Passwort ändern.
Ach so, Clients sind Windows 11 und sein Notebook noch als klassisches AD Gerät. Bei 250 Clients bis jetzt das einzige merkwürdige Phänomen.
Der Klassiker CAPS-Lock?
So trivial leider nicht, NUM Lock auch nicht. Viel schlimmer. :-(
Er konnte Windows Hello PIN und Passwort nicht Auseinanderhalten.
Also doch kein generelles Problem.
Ein bisschen Feedback zu den März/April? Updates:
a) Performance stark gesunken, selbst Acrobat Starts dauern recht lang, generell der Erststart von Anwendungen (die Probleme gibt/gab es oft mit dem neuen Intel SpeedStepping und iVm Defender/SmartAppControl/Cloudscan/..)
b) Login über Fingerabdrucksensor scheitert. Ging bisher immer einwandfrei.
Manchmal kommen Fehler als wäre die PIN nicht korrekt eingerichtet etc.
Fehlermeldungen sind unklar.
User-Passwort neu setzen hat hier ein Problem mit recht langen Passwörtern, da sagt der Passwort ändern Dialog über klassisch Strg+Alt+Entf: Das Passwort entspricht nicht der Richtlinie. Da das truncated PWD passt, muss es eine Längenrestriktion sein… Sollte aber nicht so sein..
Vielleicht helfen diese Ansatzpunkt jemanden, und wir kommen so mal wieder Microsoft auf die Schliche!
..und noch was.. seit recht kurzer Zeit ist der erste Boot einer Lenovo Workstation schwarz. Ausschalten, einschalten geht wieder.
Moin, bei der Lenovo würde ich mal nach dem BIOs schauen. Möglich, dass das nicht aktuell ist!
Bios ist natürlich aktuell.
Es bleibt nur relativ lange schwarz, deutlich länger als früher, bootet aber dennoch.
Generell plagen Lenovo/Windows massive Performanceprobleme mit Intel und deren Eco-Trends (Effizienzkerne/New "SpeedStep"), Windows Defender/SmartAppControl/…
Hier braucht es handliche (portable) Monitoring Tools und Abhilfe durch die Hersteller…