Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: darebacik 21. 11. 2025, 09:35:03
-
Ja sice nepouzivam Win, ale mam niekolko znamych, ktori Win pouzivaju. U jedneho znameho mam nastavene aby sa pomocou WoL zapinal PC kazde rano. Ak pride do prace, tak sa prihlasi (ma admin konto) a pracuje.
Dnes rano mi zavolal, ze sa neda prihlasit.
Po rozhovore ohladm numlock, Sk - EN klavesnice atd ... sme nedospeli nikde
Mam k nemu RD, tak som sa pripojil a skusal som sa prihlasit.
Samozrejme pri prihlaseni sa da heslo zobrazit, takze sme obaja videli, ze heslo je spravne, ale win stale hlasil, ze heslo je nespravne.
Takze nasledoval restart, ale ani po restarte to nefungovalo (a ani po dalsich dvoch restartoch).
Takze som zacal googlit ako heslo resetovat.
Avsak znova som sa cez rustdesk prihlasil na RD a zadal som heslo este raz.
Zaaaaazrak .... som prihlaseny !!!
Ako to casto byva, tak netreba ist na mna sposobom, ze predtym si sa musel urcite pomylit, lebo heslo som videl a predsa nie som magor.
Na PC neexistuje MS konto, pouziva sa len lokalne konto.
Na PC sa nepouziva ziadny externy AV ani firewall, len tie defenderi ktore su sucastou OS (aktualizacie su pravidelne).
Je to nejaky bug, alebo co sa deje ?
-
Videl jsem na vlastni bulvy totez.
Heslo zarucene spravne / vyresetovane. Psane na on-screen klabosnici, heslo zobrazene pred odeslanim - ano, je spravne, akorat, ze neni.
Prihlasi se jinej user a zkusi "run as" user puvodni .... heslo to sezere na prvni dobrou.
OK, nahradni user se odhlasi a ten problematickej se zkusi prihlasit znovu... ne.
Vlastne uz nevim, co bylo reseni. Snad zadani kompletne celyho prihlaseni pres kolonku Other user.
Strasna haluz. Takze ne, nehrabe vam... deje se to.
-
Tohle se mi sice osobně nikdy nedělo, ale asi bych pro jistotu ještě zkusil zkontrolovat počet špatných přihlášení, než se dočasně zamkne účet.
https://www.onevinn.com/blog/windows-11-local-account-lockout-policy
Dá se to nastavit přes politiku (Pro, Enterprise) nebo zjistit a změnit z příkazové řádky (net account).
-
kontrolní otázka... ten účet je lokální nebo doménový?
u doménového účtu jsem to viděl asi 3x, poté co zákazník olepil DNSky a ADDCčka bezpečnostními záplatami, které zakázaly staré verze TLS a SSL.
-
A ještě pozor na čas. Pokud je čas v počítači oproti doméně, ke které se přihlašuje, posunut, může dojít k problémům s přihlášením. Nejde přitom primárně o rozdíl v minutách, ale o platnost vydaných Kerberos tiketů a klíčů – pokud server považuje tiket za "neaktuální" kvůli časovému nesouladu, přihlášení se nepovede. Po synchronizaci času se to povede, pokud k té synchronizaci tedy dojde.
Zvlášť problematické jsou případy, kdy je čas v RTC nastaven jako lokální a uživatel se po jeho změně (letní/normální) nepřihlásí delší dobu. Windows pak v některých případech mylně předpokládají, že po změně systému došlo i ke změně času v RTC, a přihlášení se zablokuje.
Bohužel je čas v RTC lokální a win se toho stále drží (pokud není nastaveno jinak registru - klíč RealTimeIsUniversal)
-
Pokud by ucet byl locknutej, tak widle vetshou hlasaj, ze je locknutej.
Jinak netreba se nicemu divit, u widli je mozny uplne vsechno. Specilne u 11+.
Trebas ... https://www.borncity.com/blog/2025/11/21/windows-11-24h2-microsoft-bestaetigt-broken-by-design-durch-update-kb5062553/
Apropos, pokud na tom stroji je secureboot, honem ho vypni. A nedej boze widli sifrovani disku, to se s tim co na tom disku je, rovnou rozluc.
-
kontrolní otázka... ten účet je lokální nebo doménový?
u doménového účtu jsem to viděl asi 3x, poté co zákazník olepil DNSky a ADDCčka bezpečnostními záplatami, které zakázaly staré verze TLS a SSL.
Ne neni na domene. Je to len local a bez MS konta.
Pokud by ucet byl locknutej, tak widle vetshou hlasaj, ze je locknutej.
Jinak netreba se nicemu divit, u widli je mozny uplne vsechno. Specilne u 11+.
Trebas ... https://www.borncity.com/blog/2025/11/21/windows-11-24h2-microsoft-bestaetigt-broken-by-design-durch-update-kb5062553/
Apropos, pokud na tom stroji je secureboot, honem ho vypni. A nedej boze widli sifrovani disku, to se s tim co na tom disku je, rovnou rozluc.
Myslim, ze ked som instaloval win, tak som sec.boot vypol, ale musim to skontrolovat.
Tohle se mi sice osobně nikdy nedělo, ale asi bych pro jistotu ještě zkusil zkontrolovat počet špatných přihlášení, než se dočasně zamkne účet.
https://www.onevinn.com/blog/windows-11-local-account-lockout-policy
Dá se to nastavit přes politiku (Pro, Enterprise) nebo zjistit a změnit z příkazové řádky (net account).
Dik, necital som to cele, ale prisiel som az k tabulke kde su prednastavene hodnoty. To neviem kolko krat sa pokusal znamy o zadanie hesla. Mozno to skusil viac ako 10x a ked sa to nepodarilo, tak sa ucet blokol na 10 minut.
Po 10 minutach sa uz potom dalo pripojit.
Cize mozno je toto vysvetlenie
-
Apropos, pokud na tom stroji je secureboot, honem ho vypni. A nedej boze widli sifrovani disku, to se s tim co na tom disku je, rovnou rozluc.
Off-topic. Proč bys vypínal SB? Tím, že jsou ty loadery podepsány přímo klíčem od MS UEFI autority, co má certifikáty přímo v každém standardním počítači/desce, nikdy jsem s tím nezažil problémy. Chápu, že pokud má někdo komplikovanější multiboot s nějakým vícenásobným chainloadingem, MOK klíči atp., tak to může dávat smysl vypnout. Nebo dočasně vypnout v BIOSu, když člověk potřebuje nouzově nabootovat z nějakého nepodepsaného loaderu.
U toho device encryption (což je technicky BitLocker s ořezanými možnostmi) to chce, myslím, taky dovysvětlit.. Souhlas, že pokud má Windows Home s lokálním účtem, tak je lepší to vypnout, protože tam přesně může dojít k tomu, že ti třeba odejde deska/CPU (kde jsou v TPM klíče) a už se do toho nikdo nikdy nedostane.
Ale pokud má funkční přihlášení do Windows s MS účtem (jeden z důvodů jeho vynucování), tak se krom TPM uloží také záložní klíč automaticky na servery MS. Takže pokud k dojde k problému, dá se třeba z jiného počítače normálně stáhnout přes web a disk pak v pohodě otevřeš (třeba z jiných Windows nebo klidně z Linuxu LUKSem).
U Windows Pro nebo Enterprise je pak plný BitLocker, takže pokud někdo chce šifrování (notebook třeba) dohromady s lokálním účtem, je tam možnost předělat device encryption na normální variantu BL a uložit si záložní klíč třeba na flešku, vytisknout na papír atp.
Takže ty možnosti dávají smysl, a určitě jsou situace, kdy šifrování zapneš. Akorát to podle mě MS klasicky zvoral. Zaprvé tím, že to nevysvětluje v kontextu i s riziky. A hlavně tím, že to natvrdo, bez varování a explicitního souhlasu natlačil všem (co to neměli zakázané politikou nebo tam nevyhovovaly technické podmínky) a na pozadí zašifroval disky i s tím zmíněným rizikem, že lidé pak nemají žádné záložní klíče.
-
Off-topic. Proč bys vypínal SB?...
Kolik widli adminujes? je to tak 2 roky +- ... kdy po aktualizacich pestaly bootovat vsechny widli virtualy na vmware (se zapnutym SB) a soudruzi se pak 3 mesice dohadovali, kdo za to muze.
Aktualne pak v tom ma MS takovej bordel, ze co tyden zverejnuje jinou informaci na tema expirace certifikatu. Takze mas dost velkou sanci ze nekdy po vanocich ti ten stroj jednoduse nenabootuje.
Vazne nevim, proc bych mel resit problem, kterej neexistuje. Pokud se nekdo dostane k libovolnymu stroji fyzicky, nabootuje si na nem co chce. A pokud se dostane do beziciho systemu, mas mnohem vetsi problem nez nejakej bootloader.
A sifrovani ... lol ... jako vazne povazujes za relevantni sifrovani, ktery si uklada klice k MS? A navic zas skoncis se strojem, kterej nenastaruje (coz se stalo nejspis milionum useru) a dozaduje se aby ses (nekde jinde) prihlasil k tomu ms uctu ... a stahnul si zalozni klic? (uz vidim jak to dela bfu ...)
Vis jak vypada BFU kterej se nechal dotlacit k tomu, ze bude pouzivat ms ucet? Prijdes k nemu, chces po nem email ... "jakej?" ... tak heslo "jaky?" ... "vzdyt to rikalo ze pin staci" ... takze je v riti a k tomu ms uctu se uz nikdy nedostane.
-
Off-topic. Proč bys vypínal SB?...
Kolik widli adminujes? je to tak 2 roky +- ... kdy po aktualizacich pestaly bootovat vsechny widli virtualy na vmware (se zapnutym SB) a soudruzi se pak 3 mesice dohadovali, kdo za to muze.
To byla výborná taškařice. Aktualizace microsoftího podpisu v EFI způsobila, že žádnej post-Vista OS microsoftu nestartoval. Pár virtuálů jsem u zákazníka musel oživovat přes recovery, protože odmítali vypnutí SecureBootu, a u asi 4 ani to nezabralo a při zákazu vypnutí SB to bylo na reinstalaci .
BTW se jim to pak povedlo ještě jednou, ale to už nebyl takovej průser, protože to 1) velmi rychle rollbackli a vydali opravenou záplatu, 2) spousta provozovatelů se už poprvý poučila a SB měla vypnutej.
-
Mne sa tiez nedalo prihlasit. Lenze ja mam ms konto a skusal som ho prepnut do lokalneho. Vysledok bol taky, ze cez web som sa normalne dostal do konta, v druhom lokalnom som cez runAs vedel spustit s heslom. Ale samotne prihlasenie nic. A ked som skusil zabudnute heslo, tak uz sa nedalo prihlasit ani starym, ani novym. Ani nudzovy rezim. Najzaujimavejsie bolo, ked po cca 20tich minutach, kedy som hladal dostatocne velku sekeru sa mi normalne podarilo prihlasit na prvy krat.
-
To byla výborná taškařice. Aktualizace microsoftího podpisu v EFI způsobila, že žádnej post-Vista OS microsoftu nestartoval. Pár virtuálů jsem u zákazníka musel oživovat přes recovery, protože odmítali vypnutí SecureBootu, a u asi 4 ani to nezabralo a při zákazu vypnutí SB to bylo na reinstalaci .
BTW se jim to pak povedlo ještě jednou, ale to už nebyl takovej průser, protože to 1) velmi rychle rollbackli a vydali opravenou záplatu, 2) spousta provozovatelů se už poprvý poučila a SB měla vypnutej.
To jako ze vsechny nevirtualni stroje startovaly, nestartovaly jen virtualky a muze za to mrkvosoft?
-
A sifrovani ... lol ... jako vazne povazujes za relevantni sifrovani, ktery si uklada klice k MS? A navic zas skoncis se strojem, kterej nenastaruje (coz se stalo nejspis milionum useru) a dozaduje se aby ses (nekde jinde) prihlasil k tomu ms uctu ... a stahnul si zalozni klic? (uz vidim jak to dela bfu ...)
To je hrozny todlencto. Takova nezodpovednost! Misto aby udelali poctive sifrovani, kdy se ke klici muze dostat kdokoli a hned!
Vis jak vypada BFU kterej se nechal dotlacit k tomu, ze bude pouzivat ms ucet? Prijdes k nemu, chces po nem email ... "jakej?" ... tak heslo "jaky?" ... "vzdyt to rikalo ze pin staci" ... takze je v riti a k tomu ms uctu se uz nikdy nedostane.
Dej navrh na vylepseni minimalnich hw pozadavku windows, aby soucasti konfigurace byla tetovaci jehla, ktera by automaticky vytetovala tvym uzivatelum heslo na celo.
-
To byla výborná taškařice. Aktualizace microsoftího podpisu v EFI způsobila, že žádnej post-Vista OS microsoftu nestartoval. Pár virtuálů jsem u zákazníka musel oživovat přes recovery, protože odmítali vypnutí SecureBootu, a u asi 4 ani to nezabralo a při zákazu vypnutí SB to bylo na reinstalaci .
BTW se jim to pak povedlo ještě jednou, ale to už nebyl takovej průser, protože to 1) velmi rychle rollbackli a vydali opravenou záplatu, 2) spousta provozovatelů se už poprvý poučila a SB měla vypnutej.
To jako ze vsechny nevirtualni stroje startovaly, nestartovaly jen virtualky a muze za to mrkvosoft?
U mašin na železe jsem to nepotkal (protože servery na železe nemáme už hodně dlouho), a ano, přesně tak. Virtuály pod (nejen) VMw nestartovaly, protože ta aktualizace do EFI nahrála neplatný podpis a přepsala jím původní, který se tam zapsal při instalaci. Takže VMw odmítl takovou virtuálku s aktivní volbou SecureBoot spustit, protože takový operační systém se s aktivním SecureBootem spustit nesmí. Tam to byla jednoznačně chyba MS a kromě VMw se projevila i na HyperV.
A ten druhý případ (buď vloni na podzim letos na jaře to bylo) byl způsoben tím, že MS měnil formát podpisu, a teď z hlavy nevím jestli zapsali do EFI podpis v novém formátu a neaktualizovaný VMw ho neuměl, nebo tam zapsali starý formát a aktualizovaný VMw už spuštění s ním nepřipouštěl (musel bych to dohledávat a tím čas mařit nebudu). Tam měli máslo na hlavě oba, ale VMw víc, protože ten nový formát byl standardizován před cca 10 lety a oni ho implementovali snad až v 8u2.
-
Vazne nevim, proc bych mel resit problem, kterej neexistuje. Pokud se nekdo dostane k libovolnymu stroji fyzicky, nabootuje si na nem co chce. A pokud se dostane do beziciho systemu, mas mnohem vetsi problem nez nejakej bootloader.
A sifrovani ... lol ... jako vazne povazujes za relevantni sifrovani, ktery si uklada klice k MS? A navic zas skoncis se strojem, kterej nenastaruje (coz se stalo nejspis milionum useru) a dozaduje se aby ses (nekde jinde) prihlasil k tomu ms uctu ... a stahnul si zalozni klic? (uz vidim jak to dela bfu ...)
Vis jak vypada BFU kterej se nechal dotlacit k tomu, ze bude pouzivat ms ucet? Prijdes k nemu, chces po nem email ... "jakej?" ... tak heslo "jaky?" ... "vzdyt to rikalo ze pin staci" ... takze je v riti a k tomu ms uctu se uz nikdy nedostane.
Tenhle rant úplně nechápu.
1) pokud ti jde o to, aby si na mašině nemohl kdokoli nabootovat cokoli, máš na to v BIOS/EFI prostředky, jako zaheslování konfigurace a zablokování USBček, nastavení pouze konkrétních zařízení pro boot a zakázání všech ostatních, atd. Právě pro případ, že mašinu někdo ukradne a pak bude mít na její louskání spoustu času. A právě k tomu, aby se nešlo přihlásit do nabootovaného systému ani offline resetem hesla, je žádoucí mít doménový účet, protože tam ti UBCD nepomůže.
2) jde o to, že k tomu klíči v MS účtu se dostaneš jen se znalostí přihlášení a dnes už navíc s dvoufaktorem s platným klíčem.
3) MS účet je technicky úplně totéž, jako doménový účet v AD doméně, akorát ta doména je provozovaná microsoftem v jeho cloudu, takže ty jako koncák nepotřebuješ mít doménu zprovozněnou doma a nemusíš se o ni starat.
Jakou adresu? No přece mailovou na kterou mu chodí pošta. Plus jeho telefon, na kterém pustí Authenticator a v něm si zobrazí generátor klíče (nebo prompt) k tomu účtu, a bez kterého mu to už asi půl roku nemůže fungovat.
-
Off-topic. Proč bys vypínal SB?...
Kolik widli adminujes? je to tak 2 roky +- ... kdy po aktualizacich pestaly bootovat vsechny widli virtualy na vmware (se zapnutym SB) a soudruzi se pak 3 mesice dohadovali, kdo za to muze.
Aktualne pak v tom ma MS takovej bordel, ze co tyden zverejnuje jinou informaci na tema expirace certifikatu. Takze mas dost velkou sanci ze nekdy po vanocich ti ten stroj jednoduse nenabootuje.
U mě ani nejde o celkové množství stanic/serverů, spíš o variaci různých konfigurací. Řekněme že od toho roku 2012, kdy MS přišel se SB ve Win 8 a Server 2012, mi za cca 3-4 generace počítačů mohlo projít rukama řekněme vyšší desítky kombinací různých HW konfigurací a verzí Windows (od práce, přes individuální servery a stanice v systémech jinde, video střižny až po nějaké rodinné notebooky).
Možná jsem měl kliku, ale opravdu jsem nikdy nemusel vypínat SB kvůli nějaké aktualizaci Windows nebo chybě, téměř ve všech případech to zůstávalo zapnuté (výchozí stav).
Pokud už jsem to vypínal, tak kvůli nějakému specifickému setupu (mutliboot s Linuxem bez podepsaného SHIMu, Hackintosh) nebo dalšímu hardwaru, který měl např. starý nepodepsaný UEFI firmware (starší FC, 10GbE karty - většinou vyřešil vendor updatem) příp. tam třeba v té přechodové době byly nějaké špatně podepsané ovladače třetích stran (jenom přebalený driver do W7/WS2008, což opět vyřešil vendor).
Ten problém s VMWare a Server 2022 jsem zaregistroval před 2r., ale naštěstí se mě to vyhnulo. Pár virtuálů ve správě mám, ale ty měly Server 2016 a 2019. I když možná toho víc řešil kolega, co primárně spravuje stovky virtuálů s Windows, kdežto já spíš řeším ty Linuxové. Ale i tak, kdyby to nastalo, tak pravděpodbně udělám jen revert snapshotu před updatem. Mám vcelku striktně rozdělené disky ve virtuálech pro systém, aplikační data a databáze (už jsem si párkrát s aktualizací v daném časovém okně nabil hubu :)).
Taky jsem registroval že byly někdy vloni potíže s aktualizací DBX (blacklisty v UEFI) z updatu Windows, kdy to nedoběhlo, a pak to vyžadovalo zadání BL recovery kódu, ale opět - u strojů, které spravuju, to prošlo vše v pohodě.
Vazne nevim, proc bych mel resit problem, kterej neexistuje. Pokud se nekdo dostane k libovolnymu stroji fyzicky, nabootuje si na nem co chce. A pokud se dostane do beziciho systemu, mas mnohem vetsi problem nez nejakej bootloader.
Tak protože u mě prostě vzhledem k tomu, jak relativně málo bylo za ty roky problémů přímo souvisejících se SB, tak nenastala situace, abych prostě en-bloc vyřadil jednu bezpečnostní fíčuru nebo rovnou bez znalosti situace radil, aby první co udělali na stroji s Windows, je vypnutí SB.
Není to jen o tom, že si někdo s fyzickým přísutpem z flešky nabootuje, co chce. Jakmile zapneš SB, tak se kontrolují podpisy u všech UEFI firmwarů před startem systému, bootloader, a stejným klíčem musí být podepsané i drivery, co startují rovnou po bootu (start=0). Je pak výrazně složitější tam nasadit nějaký rootkit, případně driver, který pak následně vyřadí třeba nějaký další (EDRko, antivir, které typicky také startují po bootu..) atp.
Samozřejmě pro určité situace většinou ve firemním prostředí pak dává smysl zároveň zaheslovat BIOS a použít šifrování na disku.
A sifrovani ... lol ... jako vazne povazujes za relevantni sifrovani, ktery si uklada klice k MS? A navic zas skoncis se strojem, kterej nenastaruje (coz se stalo nejspis milionum useru) a dozaduje se aby ses (nekde jinde) prihlasil k tomu ms uctu ... a stahnul si zalozni klic? (uz vidim jak to dela bfu ...)
Hele, jo. Myslím, že je daleko menší pravděpodobnost, že se někdo dostane k recovery klíči u MS a zároveň k počítači, než že bude nějaký jouda, co třeba ukradl pani notebook z auta, číst její nešifrovaná data z disku.
Vis jak vypada BFU kterej se nechal dotlacit k tomu, ze bude pouzivat ms ucet? Prijdes k nemu, chces po nem email ... "jakej?" ... tak heslo "jaky?" ... "vzdyt to rikalo ze pin staci" ... takze je v riti a k tomu ms uctu se uz nikdy nedostane.
:D vím. Jako bys se mnou chodil na rodinné návštěvy.
Ale přece nebudu nastavovat nějaké výchozí technické řešení podle nejslabších uživatelů.
Když je to ve firmě, tak máš pod kontrolou účty a v případě BL i ty kódy pro obnovení, dají se uložit do AD.
U jednotlivců to chce opravdu dobře popsat, a přesně říct, co mají dělat.. (pokud to neudělají, není to dál můj problém).
U rodiny a kamarádů jsem mnohem trpělivější, komplet to s nimi projdu včetně těch záložních cest, mailů pro obnovu.
Netýká se to zdaleka jen počítačů s Windows. Snažím se jim vštěpovat, že jejich on-line účet (MS, Apple, Google, nebo třeba Seznam s mailem) je mnohem cennější a důležitější než kterékoliv fyzické zařízení, co mají.
Většinou to zabírá, píšeme/tiskneme hesla na papír, přidávám 2FA, když to dává smysl.. atp.
-
To byla výborná taškařice. Aktualizace microsoftího podpisu v EFI způsobila, že žádnej post-Vista OS microsoftu nestartoval. Pár virtuálů jsem u zákazníka musel oživovat přes recovery, protože odmítali vypnutí SecureBootu, a u asi 4 ani to nezabralo a při zákazu vypnutí SB to bylo na reinstalaci .
BTW se jim to pak povedlo ještě jednou, ale to už nebyl takovej průser, protože to 1) velmi rychle rollbackli a vydali opravenou záplatu, 2) spousta provozovatelů se už poprvý poučila a SB měla vypnutej.
Tak to muselo být ještě něco dalšího, protože to co jsem registroval já (ESXi 7.0u3) se fakt týkalo jen Windows Server 2022.. pak MS vydal ještě později nějaké své patche, protože ti lidi, co měli starší ESXi už od Broadcomu nedostali žádnou opravu.
-
U mašin na železe jsem to nepotkal (protože servery na železe nemáme už hodně dlouho), a ano, přesně tak. Virtuály pod (nejen) VMw nestartovaly, protože ta aktualizace do EFI nahrála neplatný podpis a přepsala jím původní, který se tam zapsal při instalaci. Takže VMw odmítl takovou virtuálku s aktivní volbou SecureBoot spustit, protože takový operační systém se s aktivním SecureBootem spustit nesmí. Tam to byla jednoznačně chyba MS a kromě VMw se projevila i na HyperV.
Zvlastni. Podival jsem se schvalne na par MS serveru okolo se zapnutym SB (byly nainstalovany 4x2019 a 2x2021) a se zadnym nikdy nebyly problemy se startem (jsou to vsechno HyperV hostitele a guesty se zapnutym SB)
-
To byla výborná taškařice. Aktualizace microsoftího podpisu v EFI způsobila, že žádnej post-Vista OS microsoftu nestartoval. Pár virtuálů jsem u zákazníka musel oživovat přes recovery, protože odmítali vypnutí SecureBootu, a u asi 4 ani to nezabralo a při zákazu vypnutí SB to bylo na reinstalaci .
BTW se jim to pak povedlo ještě jednou, ale to už nebyl takovej průser, protože to 1) velmi rychle rollbackli a vydali opravenou záplatu, 2) spousta provozovatelů se už poprvý poučila a SB měla vypnutej.
Tak to muselo být ještě něco dalšího, protože to co jsem registroval já (ESXi 7.0u3) se fakt týkalo jen Windows Server 2022.. pak MS vydal ještě později nějaké své patche, protože ti lidi, co měli starší ESXi už od Broadcomu nedostali žádnou opravu.
Já to mám potvrzený na 2016 a 2019.
-
U mašin na železe jsem to nepotkal (protože servery na železe nemáme už hodně dlouho), a ano, přesně tak. Virtuály pod (nejen) VMw nestartovaly, protože ta aktualizace do EFI nahrála neplatný podpis a přepsala jím původní, který se tam zapsal při instalaci. Takže VMw odmítl takovou virtuálku s aktivní volbou SecureBoot spustit, protože takový operační systém se s aktivním SecureBootem spustit nesmí. Tam to byla jednoznačně chyba MS a kromě VMw se projevila i na HyperV.
Zvlastni. Podival jsem se schvalne na par MS serveru okolo se zapnutym SB (byly nainstalovany 4x2019 a 2x2021) a se zadnym nikdy nebyly problemy se startem (jsou to vsechno HyperV hostitele a guesty se zapnutym SB)
Taky to nepostihlo všechny, jen některý. I v našem případě to z 80+ virtuálů postihlo jen asi 8, a to byly všechny ve stejný konfiguraci na stejným železe, na stejný verzi VMw (6.7.u3g, protože zákoši aktualizaci VMw výslovně požadovali odložit; a ne, nemůžu rozebírat proč), dokonce ve stejný doméně, jen v různejch subnetech a na různě kvalitní konektivitě.