14 september 2026 | Microsoft Windows | Active Directory | IT-säkerhet
I och med säkerhetsuppdateringen KB5124008 för Windows 11 från september 2026 kommer det just nu allt fler rapporter om ett ovanligt problem i klassiska Active Directory-miljöer.
Det är framför allt Windows 11-klienter som är medlemmar i en lokal Active Directory-domän som drabbas. Efter att uppdateringen har installerats kan den säkra kanalen (Secure Channel) mellan datorn och domänkontrollanten skadas.
Följden blir att datorn visserligen fortfarande kan nås fysiskt i nätverket, men domäninloggningen slutar plötsligt att fungera.
Vad är KB5124008?
Microsoft släppte KB5124008 den 8 september 2026 som en säkerhetsuppdatering för Windows 11 24H2 och 25H2.
Under Windows 11 25H2 leder uppdateringen till build 26200.9445, under Windows 11 24H2 till build 26100.9445. Microsoft beskriver uppdateringen i grunden som en säkerhets- och kvalitetsuppdatering.
Microsoft dokumenterar redan nu flera kända problem i samband med KB5124008, bland annat problem med Remote Desktop Services, USB-ljudenheter och Hyper-V-baserade Linux-VM:ar. Ett problem med den säkra kanalen till Active Directory finns dock ännu inte med som ett känt problem (Known Issue) i den officiella KB-dokumentationen.
Det egentliga problemet: den säkra kanalen till domänen
En domänansluten dator har ett eget datorkonto i Active Directory.
Mellan datorn och en domänkontrollant finns en så kallad Secure Channel. Den behövs bland annat för förtroenderelationen mellan datorn och domänen.
Om den här kanalen skadas kan en användare under vissa omständigheter plötsligt inte längre logga in på domänen.
Det särskilt lömska:
Användarnamnet och lösenordet är fortfarande korrekta.
Windows visar till exempel:
”Användarnamnet eller lösenordet är felaktigt.”
I själva verket beror problemet dock inte på användarens lösenord, utan på datorns förtroenderelation till domänen.
Typisk felbild
I ett fall som en administratör publicerade och som gick att återskapa uppträdde följande beteende:
Windows 11 25H2
Build 26200.9445
Uppdatering KB5124008
klassisk Active Directory-domän
Domänkontrollant med Windows Server 2019
Efter installationen av uppdateringen fungerade inloggningen till en början fortfarande. Efter en tid var förtroenderelationen dock skadad.
Administratören kunde återskapa felet på flera enheter: installera uppdateringen → problemet uppstår → ta bort uppdateringen → problemet försvinner. Efter en ny installation av KB5124008 uppstod felet igen.
Intressant är dessutom att även en annan administratör rapporterar problem med domänkontrollanter på Windows Server 2022. I andra erfarenhetsrapporter beskrivs problemet till och med för olika versioner av domänkontrollanter. Det talar för närvarande emot att förhastat utgå från ett fel som enbart är begränsat till Windows Server 2019.
Så kontrollerar du felet
Om en drabbad dator fortfarande kan startas med ett lokalt administratörskonto eller via cachelagrade domäninloggningsuppgifter kan Secure Channel-anslutningen kontrolleras med PowerShell.
Som administratör:
Test-ComputerSecureChannel
Vid en fungerande Secure Channel bör följande returneras:
True
På en drabbad dator kan däremot:
False
visas.
Dessutom kan man kontrollera med nltest:
nltest /sc_query:DOMAIN
Då kan till exempel felet
ERROR_NO_TRUST_LSA_SECRET (1786)
uppstå.
Exakt den här felbilden dokumenterades i Microsoft Q&A-ärendet.
Viktigt: Återställ inte användarlösenordet direkt
Felbilden lockar till att först återställa lösenordet för den berörda användaren.
I det här fallet är det dock normalt sett inte rätt väg att gå.
Om flera användare på samma dator plötsligt inte längre kan logga in via domänen, medan exempelvis en cachad inloggning fortfarande fungerar offline, bör man först kontrollera datorns förtroenderelation.
Ett typiskt tecken är att:
Test-ComputerSecureChannel
returnerar:
False
Möjligt reparationsförsök
Som ett första reparationsförsök kan man återupprätta Secure Channel:
Test-ComputerSecureChannel -Repair
vid behov tillsammans med inloggningsuppgifterna för ett domänkonto med motsvarande behörighet.
Alternativt kan datorkontots lösenord återställas med PowerShell.
Här bör man dock vara försiktig:
I de fall som hittills rapporterats har reparationen inte alltid varit varaktigt framgångsrik.
I det ursprungliga Microsoft Q&A-fallet räckte exempelvis inte Test-ComputerSecureChannel -Repair. Där behövde datorn till slut tas bort från domänen och därefter läggas till i domänen igen.
Andra administratörer rapporterar däremot att Repair-kommandot åtminstone tillfälligt har hjälpt. Felbilden verkar därför inte vara identisk på alla berörda system.
Om reparationen inte räcker
Om Secure Channel fortfarande är trasig kan en ny domänanslutning (Domain Join) krävas som en mer omfattande åtgärd.
Förenklat:
Möjliggör lokal inloggning med ett administratörskonto
Ta bort datorn från domänen
Starta om datorn
Lägg till datorn i domänen igen
Starta om igen
Testa domäninloggningen
I det dokumenterade reproduktionsfallet var exakt detta förfarande nödvändigt för att åtgärda felet permanent.
Bör KB5124008 hållas tillbaka för närvarande?
Här bör man göra skillnad.
KB5124008 är en säkerhetsuppdatering och bör inte bara avinstalleras rakt av i alla miljöer.
Samtidigt bör administratörer med klassiska Active Directory-miljöer för närvarande följa installationen särskilt uppmärksamt.
Med KB5124008 publicerar Microsoft viktiga säkerhetsförbättringar. Uppdateringen distribueras dessutom via Windows Update, Windows Update for Business och WSUS.
För produktionsmiljöer rekommenderas därför en kontrollerad utrullning:
Testgrupp → observera → större grupp → fullständig utrullning
och inte nödvändigtvis:
Uppdatera alla klienter samtidigt.
Särskilt för enheter som behövs för användarnas dagliga inloggning bör det dessutom finnas ett lokalt administratörskonto eller en fungerande återställningsmöjlighet.
Vad vi rekommenderar just nu
För företag med klassiskt Active Directory rekommenderar vi för närvarande:
1. Kontrollera berörda Windows 11-versioner
På en klient:
winver
eller:
Get-ComputerInfo | Select WindowsProductName, WindowsDisplayVersion, OsBuildNumber
2. Kontrollera om KB5124008 har installerats
Get-HotFix -Id KB5124008
3. Kontrollera Secure Channel vid inloggningsproblem
Test-ComputerSecureChannel
4. Försök först med en reparation om resultatet är False
Test-ComputerSecureChannel -Repair
5. Dokumentera orsaken vid återkommande problem
Framför allt bör följande uppgifter dokumenteras:
Windows-version
OS-build
installerade KB-uppdateringar
Version av domänkontrollanten
Tidpunkt när problemet uppstod
Resultat av Test-ComputerSecureChannel
Resultat av nltest /sc_query
Händelser på klient och domänkontrollant
På så sätt går det betydligt lättare att avgöra om det verkligen finns ett samband med uppdateringen.
Ingen slutgiltig orsak bekräftad ännu
Här krävs en viktig reservation:
Sambandet mellan KB5124008 och skadade Domain Secure Channels rapporteras för närvarande som reproducerbart av administratörer, men är i dagsläget inte upptaget som ett motsvarande Known Issue i Microsofts officiella KB-dokumentation.
Den ursprungliga rapporten från Microsoft Q&A beskriver en reproducerbar situation med Windows 11 25H2 och domänkontrollanter med Windows Server 2019. Fler administratörer rapporterar liknande problem, bland annat med Windows Server 2022.
Också därför bör man inte förhastat påstå att KB5124008 definitivt är orsaken till varje aktuellt ”Trust Relationship”-fel.
Andra orsaker som DNS-problem, tidsavvikelser, problem med datorkontot eller nätverks-/VPN-komponenter måste fortfarande uteslutas.
Slutsats
KB5124008 bör för närvarande följas särskilt noga i Active Directory-miljöer.
Om flera användare av en Windows 11-dator efter septemberuppdateringen plötsligt inte längre kan logga in på domänen, trots att inloggningsuppgifterna är korrekta, är det värt att titta närmare på datorns förtroenderelation.
Det viktigaste första testet är:
Test-ComputerSecureChannel
Om kommandot returnerar False föreligger med stor sannolikhet ett problem med datorns Secure Channel till domänen.
Eftersom rapporterna hittills visar att en enkel reparation inte hjälper varaktigt på alla system bör man dokumentera berörda enheter noggrant och inte förhastat ändra användarkonton eller lösenord.
Detta inlägg uppdaterades senast: 14 september 2026.
Vi följer utvecklingen kring KB5124008 och uppdaterar detta inlägg så snart Microsoft publicerar ett officiellt uttalande eller en motsvarande korrigering.