Hoppa till innehåll

Windows 11 KB5124008: Domänförtroendet kan brytas efter uppdateringen

14 september 2026 av
Windows 11 KB5124008: Domänförtroendet kan brytas efter uppdateringen
Nanti Phooprasert | Biricon IT Services GmbH


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:

  1. Möjliggör lokal inloggning med ett administratörskonto

  2. Ta bort datorn från domänen

  3. Starta om datorn

  4. Lägg till datorn i domänen igen

  5. Starta om igen

  6. 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.