Beheerders zien inlogproblemen op domeincontrollers na Patch Tuesday-ronde

Microsoft waarschuwt dat de Patch Tuesday-update van mei voor problemen kan zorgen met de authenticatie van sommige diensten. De update veroorzaakt problemen op apparaten met Windows 11 en Windows Server 2022 die als domeincontrollers worden gebruikt.

Microsoft schrijft in een update dat de installatie van update KB5013943 problemen kan opleveren op Windows-versies. Het gaat om vrijwel alle Windows-versies inclusief 10 en 11, en zelfs 7 en 8.1, en Windows Server vanaf versie 2016 tot aan 2022. Het probleem komt voor nadat beheerders de update installeren die tijdens de Patch Tuesday van mei werd verstuurd. Volgens Microsoft gaat het alleen om apparaten die worden gebruikt als domeincontrollers. Client-apparaten en Windows Servers die niet als controller worden ingezet hebben geen last van de problemen.

Verschillende systeembeheerders klagen op forums als Reddit dat ze problemen met de patch ervaren. Microsoft bevestigt dat er authenticatieproblemen ontstaan door de patch. Dat zou voorkomen in verschillende diensten, waaronder de Network Policy Server, de Routing and Remote Access Service, Radius, het Extensible Authentication Protocol en het Protected Extensible Authentication Protocol, maar mogelijk vallen ook andere diensten uit Windows onder de bug.

De problemen worden volgens Microsoft veroorzaakt door een patch die twee beveiligingslekken oplost. Tijdens de afgelopen Patch Tuesday werden twee privilege escalation bugs, CVE-2022-26931 en CVE-2022-26923, gerepareerd in Kerberos. De nieuwe problemen hebben te maken met de manier waarop de domain controller certificaten mapt. Microsoft raadt aan om als mitigatie handmatig certificaten toe te wijzen aan machines via Active Directory, in ieder geval tot er een update beschikbaar komt die het probleem oplost. Het is nog niet bekend wanneer dat is.

Reacties (73)

[RKD]

Volgens het reddit topic is het niet beperkt tot alleen Server 2022, maar komt het ook voor op 2012R2, 2016 en 2019 NPS Servers

[Drardollan]

Dat is ook wat Microsoft aangeeft:

Affected platforms:

Server: Windows Server 2022; Windows Server, version 20H2; Windows Server, version 1909; Windows Server, version 1809; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2

https://docs.microsoft.co...er-or-client-for-services

[Triblade_8472]

De vraag is of MS gelijk heeft dat het echt alleen op DCs voorkomt of ook op losse NPS servers.
Edit, nee, het lijkt er dus op dat wanneer het NPS betreft het altijd op een DC geïnstalleerd is.

[Reactie gewijzigd door Triblade_8472 op 22 juli 2024 18:45]

[etamminga]

Nee ook NPS servers die niet op een domain controller zitten hebben er last van. #ervaring
LDAP Communicatie tussen NPS en DC stopt met werken.

[Triblade_8472]

Ik vind de waarschuwing heel vaag.

Ze doen alsof het een Windows 11 issue is, maar ondertussen leggen ze de schuld bij de mei 2022 update voor servers waar de Domain Controller op draait. Ja Microsoft, wat is het nu??

Volgens Reddit is het niet installeren of het de-installeren van de onderstaande server (met DC rol)
updates voldoende om alles weer te laten werken.

Ik heb de volgende updates maar tegengehouden in WSUS:
Windows Server 2016
2022-05 Cumulative Update for Windows Server 2016 for x64-based systems (KB5013952)

Windows Server 2019
2022-05 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5013941)

Windows Server 2022
2022-05 Cumulative Update for Microsoft server operating system version 21H2 for x64-based Systems (KB5013944)

[Reactie gewijzigd door Triblade_8472 op 22 juli 2024 18:45]

[CreatoX]

Wat ik nooit begrijp is dat Microsoft het heeft over één KB (KB5013943) en het onderwater een bulk andere KB's betreft. Het is altijd een speurtocht om er achter te komen welke KB nummers voor welke systemen geldt. Of hebben jullie hier een andere methode voor?

Het is bij Server 2016+ natuurlijk sowieso een issue. Want het uitsluiten van een Cumulatieve Update zal ook een boel andere updates tegenhouden die bepaalde kwetsbaarheden en problemen oplost. Tja, die willen we wel graag geïnstalleerd hebben.

Tot zover het lijstje van wat ik her en der verzameld heb:

KB5013941 2022-05 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5013941)
KB5013943 2022-05 Dynamic Cumulative Update for Windows 11 for ARM64-based Systems (KB5013943)
KB5013952 2022-05 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5013952)
KB5013941 2022-05 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5013941)
KB5013944 2022-05 Cumulative Update for Microsoft server operating system version 21H2 for x64-based Systems (KB5013944)
KB5014001 2022-05 Security Only Quality Update for Windows Server 2012 R2 for x64-based Systems (KB5014001)
KB5014011 2022-05 Security Monthly Quality Rollup for Windows Server 2012 R2 for x64-based Systems (KB5014011)

[Triblade_8472]

In dit geval betreft het de mei update. Ik ga dan naar WSUS en zoek op 2022-05. Dan rolt alles eruit wat deze update betreft. Of ik kan in ieder geval cherry picken uit een relatief korte lijst.

Het is zeker een probleem. Daarom ben ik zo vreselijk tegen dat nieuwe systeem van cumulatieve updates.
Microsoft weigert brakke updates uit een CU te halen omdat het pakket dan instort ofzo.

Beter waren de berg losse updates waar MS er gewoon 1 uit kon terugtrekken...

[Auriso]

We hebben dit probleem vanmorgen ondervonden. Met name in de combinatie met certifcate authenticatie Windows 10 clients t.b.v. een Wifi oplossing. Workaround: KB5013941 de-installeren op w2019 DC's en w2019 NPS.

[Polderviking]

Dit is waarom ik die server updates altijd een paar weken laat marineren voordat ik ze installeer... die kwaliteit van de updates is echt niet meer wat het ooit was.

[Reactie gewijzigd door Polderviking op 22 juli 2024 18:45]

[segil]

Daarvoor heb je het otap principe. Eerst testen in ota, daarna uitrollen in productie. En kan je prima patches binnen 1-2 weken uitgerold hebben.

[Polderviking]

Daarvoor heb je het otap principe. Eerst testen in ota, daarna uitrollen in productie.

OTAP in het MKB. Denk dat je daar blij mag zijn als je genoeg budget hebt om alles een beetje courant te houden.
En dat vind ik niet eens persé onterecht als je kijkt wat hier nu weer kapot gaat.
Die updates die ze pushen moeten gewoon eens ophouden allerlei super doorsnee dingen kapot te maken.
Domein aanmelding is niet bepaald een "edge case" die er bij testen doorheen glipt.

[Reactie gewijzigd door Polderviking op 22 juli 2024 18:45]

[Anoniem: 316512]

MKB kan ook zo'n 200 man zijn hè, daar kan je echt wel een OTAP oplossing verwachten.

Dat de bakker en de kapper daar niet aan meedoen, is weer wat ameer te begrijpen.

[Polderviking]

Ik denk dat vooral Microsoft aan de OTAP moet.

[Glashelder]

Die zijn er juist van afgestapt. Die zijn erachter gekomen dat je beter users in rings kan laten testen. Af en toe explodeert dat in je gezicht, zoals nu weer..

[segil]

dat kan wel zo zijn, maar ook in productie kan je je patches verdelen over 2 rondes. Eerste weekend na patch tuesday doe je de low impact servers, weekend erna high impact. Ene dc in eerste weekend, andere dc in ander weekend. Op die manier kan je ook al makkelijker issues opsporen en fixen.

[MazDaMan1970]

In de meest ideale situatie heb je een OTAP-straat. In de praktijk kom ik dat helaas maar bar weinig tegen, bij de diverse bedrijven waar ik gewerkt heb en dan is het gewoon iedere maand maar weer hopen dat het goed gaat..

[segil]

en wat voor bedrijven zijn dat? MKB? Groot zakelijk?

[MazDaMan1970]

Productie bedrijven; waarbij ICT als een sluitpost wordt gezien en er dus te weinig in ICT geïnvesteerd wordt. Mede daarom ga ik nu weer bij een softwarebedrijf werken, waarbij ICT dus niet als sluitpost wordt beschouwd.

[segil]

ik ziet het eerder terug bij MKB bedrijven en minder bij middel/groot zakelijk. Daar is het gangbaarder om een otap omgeving te hebben.

[MazDaMan1970]

MKB bedrijven hebben over het algemeen geen eigen ICT afdeling meer en bij grote bedrijven kom je het meestal alleen tegen als daar nog developers in vaste dienst zijn.

[XephireUK]

Ik heb voor een grote internationale bank in Londen gewerkt, en OTAP/DTAP bestaat daar niet. De systemen zijn zo complex door allerlei fusies etc. dat men in productie test. Toen ik daar 6 maanden zat, werden er 100 sub-system uitgeschakeld omdat ze die niet meer nodig hadden. Sommige bedrijven hebben niet eens 100 systemen...
Fusie met een nieuwe bank: bouw een API om de nieuwe systemen aan de oude te koppelen. Integratie van de nieuwe bank in de oude systemen werd volgens mij niet gedaan.

[Platpoot]

OTA is ook niet heilig, helemaal niet als je het over DC's hebt.
Test maar eens al je mogelijke scenario's binnen een week, exact zoals een eindgebruiker en applicaties het ook gebruiken. Ik geloof daar echt niet in. Uiteraard is het goed om te doen hoor, en je haalt er ook zeker waardevolle info uit, maar ik zie het meer als onderdeel van het marineren. En een paar weken, dat is in ons geval tot 4 weken. Wat ik vaak op bv reddit zie is dat er genoeg (productie)omgevingen gewoon direct op de dinsdag worden gepatcht. Daar kan ik niet echt bij.

[eagle00789]

Wij installeren altijd patch-1 oftewel we lopen altijd een patchronde achter, juist vanwege dit soort gezeik.

[SirBlade]

Iedere organisatie zal een afweging moeten maken tussen beschikbaarheid en veiligheid. Wij moeten direct te dev/test servers patchen en alleen als er daar grote problemen ontstaan mogen we de patch op productieservers tegenhouden. Uit voorzorg langer wachten is hier sinds er de AVG verboden.

[Dennisb1]

De update veroorzaakt problemen op apparaten met Windows 11 en Windows Server 2022 die als domeincontrollers worden gebruikt.

Hoe ga je een Windows 11 bak als domeincontroller gebruiken dan? Wie bedenkt dit...

[core_dump]

Ik denk dat het meer gaat om inloggen met een Windows 11 computer op een 2022/2019/2012/2008 domain controller

[Dennisb1]

Uit de volgende alinea:

Client-apparaten en Windows Servers die niet als controller worden ingezet hebben geen last van de problemen.

[Daoka]

Misschien lees ik het verkeerd maar ik zie het als "Client-apparaten" en "Windows Servers die niet als controller worden ingezet". Of te wel het gaat om de servers + de cliënten die daarop aanmelden.

[orvintax]

Dat moet verkeerd geschreven zijn, zover ik weet is die mogelijkheid er niet.

[QuatroXL]

Lees je het niet verkeerd? Is het niet bedoeld dat het probleem zich voordoet op apparaten met Windows en en Windows server 2022 en die laatste specifiek met de rol van DC? Inmiddels lijken er meer smaakjes server te zijn geraakkt.

[Bas_B]

Het is een beetje ambigu, maar je kan het ook zo lezen:
De update veroorzaakt problemen op apparaten met:
- Windows 11
- Windows Server 2022 die als domeincontrollers worden gebruikt.

M.a.w. kan goed dat Win11 er altijd last van heeft, ongeacht of je deze 'inzet' als domain controller.

[beerse]

Het algemene advies is altijd dat er meer dan 1 domein-controler in een active-directory-domein is.
Net als met clusters en dergelijke zou ik 1 zo'n machine patchen en bijwerken. De andere een paar dagen (weekje) later.

[MazDaMan1970]

Ten dele heb je gelijk, ware het niet dat DC's met elkaar syncen. Dus als er 1 op een ander patchlevel zit, dan kun je daardoor ook weer tegen gekke problemen aanlopen...

[beerse]

Zeker weten, verschillende patch levels geven 'vreemde' gedragen: Vooral dingne die instabiel lijken omdat een member server naar de 'oude' dc kijkt en daar alles als van ouds is en naar de 'nieuwe' dc kijkt en daar dit issue ervaart. Zolang je dat herkent en erkent is het geen probleem als de dc-s een weekje op een verschillend os-patchlevel zitten.

In de regel zijn de patches die uitgebracht worden compatibel of upwards compatibel. Dat wil zeggen dat de basis functionaliteit wel gelijk is en dat je ze naast elkaar kan gebruiken als je maar uit gaat van de 'minste' van de beschikbare varianten.

[MazDaMan1970]

Zo gauw er niks veranderd wordt aan het AD-scheme, door een update, zou het geen problemen moeten geven. Maar helaas weet je dat niet altijd goed van te voren, tenzij je de tijd en moeite wil nemen om van alle patches de release info te lezen.

[beerse]

Maak je geen zorgen, het ad-schema wordt echt niet door microsoft patches aangepast. Zelfs als je een nieuwe versie van msWindows als ad-controler wilt gaan gebruiken moet je bewust en zelf het ad-schema aanpassen.

En dan, de aanpassingen van het ad-schema vanuit microsoft zijn in de regel aanvullingen en uitbreidingen, dat is altijd upwards compatibel.

Tel daar bij dat iedereen zelf uitbreidingen kan en mag doen aan dat schema. Als/zolang je dat volgens de regelen der kunst doet, zal microsoft niet aan jou uitbreidingen komen. Er is genoeg software die dergelijke uitbreidingen doet.

Enneh, ja, de release info van patches, die neem ik wel degelijk door als ik denk dat ze mij raken.

[Reactie gewijzigd door beerse op 22 juli 2024 18:45]

[MazDaMan1970]

Microsoft zal dat idd niet zonder waarschuwing gaan aanpassen, maar mocht je zo'n waarschuwing om wat voor een reden dan ook gemist hebben, dan kun je voor gekke verrassingen komen te staan.

[Reactie gewijzigd door MazDaMan1970 op 22 juli 2024 18:45]

[beerse]

Zelfs dat valt mee. Een schema is 'alleen maar' wat er allemaal bedient kan gaan worden. Een klein voorbeeld is bijvoorbeeld het laps systeem, waarbij/waarmee de local-admin wachtwoorden vanuit ad bedient worden. In ad zie je dan bij de computers 2 nieuwe attributen verschijnen met bepaalde rechten en plichten daar bij. Daarvoor is er bij de installatie een schema uitbreiding: Iedere computer in het AD krijgt die 2 attributen er bij met daarbij de rechten en plichten en ook de default-waardes daar bij. Dat staat in dat schema.

Als microsoft nu een update geeft van het schema, dan zouden de default waardes van die wachtwoorden aangepast kunnen worden. Maar de waardes die in de computers zijn opgeslagen zullen ze nooit aanpassen. Misschien worden de rechten op die attributen (wie ze mag lezen en wie ze mag aanpassen) wat aangepast of aangescherpt maar dat zal de werking niet veranderen en vooral ook de werking van het hele laps gebeuren niet aantasten.

Zo zit dat met het hele schema.

En dan nog: Als ergens iemand iets aan het schema aanpast, bijvoorbeeld dat ze het laps-deel van het schema weggooien. Dan nog blijven de attributen bij de computers gewoon staan. Het is alleen dat nieuwe computers die attributen (standaard) niet mee krijgen. Ook de rechten en plichten op die attributen kunnen eventueel aangepast worden maar door het weggooien van het schema blijven de rechten die op de bestaande computer attributen staan gewoon aanwezig.

Dus ja, als het schema wordt aangepast of delen worden gewist, dan kan het een zootje worden maar dat gebeurt niet direct. En als dat dan wel gebeurt dan is dat in de regel bij de overgang naar nieuwe versies van het OS. Bij de overgang van W2012 naar W2016 (of volgende stappen) kunnen/zullen schema delen die al sinds W2008 niet meer worden gebruikt opgeruimd kunnen worden. Niemand heeft tegenwoordig meer iets aan instellingen voor 16 bits delen van het os, met het uitfaseren van 32-bits windows zijn 16 bits applicaties niet meer mogelijke en kunnen bijgaande instellingen ook weg.

[MazDaMan1970]

Daarom wacht ik altijd minimaal een week met het installeren van Windows updates. Quality-control is bij MS de laatste jaren een ramp, sinds de checks geautomatiseerd zijn en een groot deel van de verantwoordelijke werknemers wegbezuinigd zijn.

[locke960]

Wat ook niet helpt is dat de updates tegenwoordig alles of niets zijn. Vroeger kon je er nog voor kiezen een problematische update niet te installeren zonder ook alle andere security fixes af te wijzen.

Heb zelf meerdere keren meegemaakt dat print/spooler gerelateerde updates problemen veroorzaakten op print servers, terwijl de bug die gefixed werd in mijn geval geen risico vormde. Ik kon niet enkel de print/spooler patch terugdraaien, ik moest de hele monthly update verwijderen, en daarmee ook alle andere security fixes, waarvan sommige eigenlijk wel van belang waren.

[Reactie gewijzigd door locke960 op 22 juli 2024 18:45]

[walteij]

WSUS of Intune gebruiken om je bedrijfssystemen te updaten helpt dan al een hele boel.

[SunnieNL]

Volgens mij niet. Die kunnen een patch terugdraaien, maar dat is altijd de volledig rollup pack van die maand. Je kunt niet zeggen dat je maar een onderdeel van de totale maandelijkse patch wil terugdraaien.

[walteij]

We hebben beiden gelijk
In WSUS kun je de specifieke updates goed- of afkeuren, in Intune kun je inderdaad alleen een update deinstalleren.

[MazDaMan1970]

Klopt, heb dit jaar al 2x problemen gehad met printer-gerelateerde patches. MS moet echt sterk zijn update-beleid gaan verbeteren, anders gaan straks nog meer bedrijven over op Linux.

[TheVivaldi]

En niet alleen dat, maar Microsoft waarschuwt ook dat diverse apps niet meer werken na deze update: https://www.ghacks.net/20...kb5013943-may-break-apps/

[Widow]

En als je een stukje code zoekt om snel op je servers te kijken of je deze update hebt, hier is ie. Aftrappen met Powershell.

if(get-hotfix -id KB5013943 -EA 0){
Write-Host 'KB installed'
}else{
Write-Host 'KB not installed'
}

[Reactie gewijzigd door Widow op 22 juli 2024 18:45]

[dasiro]

of in je WSUS (of alternatief) gewoon het rapport van de desbetreffende update bekijken

[Qalo]

Het begint toch wel zo'n beetje pijnlijk te worden voor alle Windows gebruikers. Zowat bij elke update zijn er wel problemen. Je zou maar afhankelijk zijn van zo'n systeem.

Ik draai een ander systeem dan Windows in 99% van mijn computertijd, en ik krijg regelmatig updates op die systemen. Maar daarop wer-ke-lijk NOOIT gezeik (of ik heb er niks van gemerkt, dat kan ook!). Microsoft zou zich inmiddels de ogen uit de kop moeten gaan schamen voor die constante stroom aan problemen na zo'n pleisterdinsdag....

[Anoniem: 316512]

Zelf ook nooit problemen met mijn Windows client. En met Kali Linux en ParrotOS wel weer een stuk meer.

Het ligt er ook maar net aan wat je allemaal met je machines doet. Zomaar "M$'-achtige opmerkingen roepen vind ik een beetje achterhaald. Microsoft heeft enorm sterke oplossingen tegenwoordig.

[rakkels]

Ik snap die MS bash echt niet. Hun client os(incl wsl), server OS, cloud services, xtreem veel oplossingen die op linux/open source gebaseerd Zijn-- hun bijdragen aan open source initiatieven

Ik heb echt weinig problemen... Ik vind MS echt superbedrijf

Al dat gepiep... Als er iets niet goed gaat, is het altijd snel te verhelpen.

toevoeging:

De gemelde vulnerability van dcom is veel verder reikend. Ik zou me daar op gaan focussen (want: wu deze maand meldt nu wanneer dcom niet voldoet. Over maanden worden componenten van dcom uitgezet en werkt je applicatie server niet meer

[Reactie gewijzigd door rakkels op 22 juli 2024 18:45]

[hiostu]

Tja, ik draai al jaren Windows en nu Windows 11 op al mijn machines. Heb ook nooit gezeik gehad na installeren updates. N=1 zegt niet zo heel erg veel. Je hoort bij alle soorten OSen issues bij mensen na updates. Bij Apple komt het ook regelmatig voor. Daar hoef je als gebruiker echter nooit tegen aan te lopen.

[Qalo]

Bij rolling Linux systemen zijn er heel soms hele kleine issues die met één, of hooguit twee toverspreuken in de terminal verholpen kunnen worden (had ik laatst bij Manjaro, waarbij KeepassXC na een systeemupdate/upgrade niet meer wilde starten (nieuwe qt5 libs dan waar KeepassXC op draaide). Maar één commando in de terminal en het was opgelost.

Onder Linux Mint heb ik al helemáál nooit issues. Dat is ook mijn heavy-duty werkpaard waar ik alle cruciale zaken op doe (werk enzovoorts). Ik moet er niet aan denken dat ik steeds tegen issues aan moet lopen terwijl je je computer gewoon nodig hebt om productie mee te draaien. Ik zou dat niet meer onder Windows durven. Hoewel aanwezig op deze computer waar ik dit op tik, ik gebruik 'm zelden voor mijn werk. Ik wil een systeem waar ik op kan bouwen en vertrouwen. En dat is, vanwege de updateproblematiek onder Windows, niet het geval. "Jammer maar helaas", zou Dolf Brouwers hebben gezegd.

[batjes]

Powershell is net zo krachtig als een terminal. Als je weet wat je doet zijn er maar weinig problemen in Windows die je niet "met 1 toverspreuk" kan oplossen.

Zelf gebruik ik Debian privé behoorlijk veel en op mijn desktop al ruim 10 jaar Windows only. 1 Windows systeem vs 5-10 Debian systemen. Windows heb ik de afgelopen 10 jaar wel 2 keer opnieuw moeten installeren nadat het dusdanig stuk ging dat een herinstallatie de snelste oplossing was.

De afgelopen 2 jaar heb ik 4 Debian machines opnieuw moeten installeren. Niet door updates, 2 door een powerloss, dag dag file index van ext4 (en poef al je data is waardeloos/onherstelbaar) en 2 keer vanwege kernel panics om <weetikveelwatvoorreden> na een herstart.

Windows is veel 'zelfvoorzienender'. Ik weet zeker dat Windows ook wel eens onderuit klapt, maar die lost het dan vervolgens zelf ook 99/100 keer weer op. Linux is veel meer "Er ging iets mis, GL&HF"

[MazDaMan1970]

Van alle Linux distro's die ik gebruik is Debian het meest stabiel. Manjaro heeft bij mij 2x voor grote problemen gezorgd na een update, dat is blijkbaar de prijs die je betaalt voor bleeding edge...

[MazDaMan1970]

Als consument zijnde heb je daar minder last van, omdat het afgelopen jaar vooral patches voor servers voor problemen hebben gezorgd. Overigens had ik dit jaar ook een groot probleem op mijn privé laptop; 1 of andere update had diverse audio codecs om zeep geholpen.