Original Summary

wdnmd的微软啊，电脑管理员账户莫名其妙被锁定了，罪魁祸首居然是edge。 通过远程桌面使用一个windows服务器，安全配置是： UAC需要管理员密码（ 在安全桌面上提示管理员凭据 ） 5次登录失败自动锁定账户24小时 在一个UAC窗口中，我输入了密码，但windows突然告诉我账户锁定了。我当时就慌了，都不敢关闭远程桌面——毕竟一旦关闭就24hrs内无法进入服务器了啊。 想要诊断问题也没法子——因为我没法获得管理员权限！（ 想要获得管理员权限？过UAC再说！想过UAC？告诉我管理员密码！你给了管理员密码？当前账户已经被锁定！ ） 于是在服务器上仔细检查配置发现了一个计划任务的权限没有配置好，可以导致管理员用户组在不经过UAC的情况下获得高完整性令牌，借此进行了权限提升 ，然后打开事件查看器查看究竟是什么东西把账户给锁定了，结果是一个webview2程序重启了五次，每次webview2启动的时候都会启动微软的神秘bug进行一次失败的本地账户验证，导致当前账户被锁定了。哈哈。 之后进行了复现，只要是打开全新的msedge / webview2进程并使用全新的user data dir，就会出现一次本地账户登录失败的请求，windows默认设置是连续失败五次直接锁定账户半小时。也就是说，如果你的某个注册机使用的是ms edge driver来模拟浏览器，那么很轻松地你的电脑就会被锁定。 这是已知问题，但是没有修复，只有缓解方案： github.com/MicrosoftEdge/WebView2Feedback [Problem/Bug]: WebView2 Runtime 153.0.4234.x performs a failed interactive logon (event 4625, SubStatus 0xC000006A "wrong password") as the current local user on every environment creation — can lock out Windows accounts on machines with account-lockout policies 已打开 02:43AM - 20 Sep 26 UTC ys-ll tracked regression ### Description Starting with WebView2 Runtime 153.0.4234.x, every WebView2 … environment creation (i.e. every new browser root process) triggers a Windows interactive logon attempt using the current local user's username with a wrong/invalid password. Each attempt records an Event 4625 on machines with failure auditing enabled and increments the bad-password count of the local account. On machines with an account lockout policy (e.g. "lock after 3 invalid logon attempts" — commonly enabled to mitigate RDP brute force), repeatedly launching any WebView2 app locks the current Windows user out — PIN and password login both stop working. The behavior does not exist in WebView2 Runtime 144.0.3719.115: same host apps, same machine, same session — zero logon attempts. ### Environment - OS: Windows 10 Enterprise LTSC 2021 (19044), x64 — and Windows 11 Insider Build 26200.9457 (separate user report, see below) - WebView2 Runtime (Evergreen, latest stable): 153.0.4234.48 — affected; 153.0.4234.32 — affected (independent report); 144.0.3719.115 / 144.0.3719.93 — not affected - Windows session: local (non-domain) account, linked Microsoft account (MicrosoftAccount:target=SSO_POP_User / SSO_POP_Device present in Credential Manager) - No system proxy configured on the machine ### Repro steps 1. Enable failure auditing: auditpol /set /subcategory:{0CCE9215-69AE-11D9-BED3-505054503030} /failure:enable 2. Launch any WebView2 app (our product, a minimal test host, or a third-party WebView2 app) on a machine with Runtime 153.0.4234.48 3. Check the Security log → Event 4625 appears ~0.3–2 s after the root process is created, one event per environment creation 4. Downgrade the runtime by installing 144.0.3719.115 → same test produces zero 4625 events 5. Upgrade back to 153 → 4625 events return immediately (deterministic) Verified with identical results for: | Host app | Runtime | 4625 per launch | |---|---|---| | Our product (a Wails v3 app) | 153.0.4234.48 | 1 | | A 30-line minimal WebView2 host (go-webview2, no framework, no business code, navigates to a data: URL) | 153.0.4234.48 | 1 | | A third-party WebView2 app (not Wails) | 153.0.4234.48 | 1 | | All of the above | 144.0.3719.115 | 0 | So it is independent of both the hosting framework and application code. ### Observed Event 4625 (full fields) `` Status: 0xC000006D SubStatus: 0xC000006A (wrong password) FailureReason: %%2313 (Unknown user name or bad password) LogonType: 2 (Interactive) LogonProcessName: Advapi AuthenticationPackageName: Negotiate WorkstationName: <local machine> ProcessName: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\153.0.4234.48\msedgewebview2.exe (browser root process) IpAddress / IpPort: - / - (local, no network peer) LmPackageName: - KeyLength: 0 TargetUserName: <current local account> ` Timing: the event fires ~0.3–2 s after root msedgewebview2.exe process creation — before any page navigation completes — and exactly once per environment creation (no retries). ### Impact - Every app launch adds a bad-password failure. On machines with a lockout policy, repeatedly launching WebView2 apps locks the account; users experience simultaneous PIN and password lockout. - Frequent-launch apps (terminal/utilities) are hit hardest; resident apps may only trigger once per boot. - We believe most users don't notice because Event 4625 is not audited under default Windows configuration. - We suspect (unconfirmed) the trigger requires a Microsoft-account-linked session (SSO_POP credentials present); we have not yet tested a session without a linked MSA. ### Investigated and ruled out - Not app code or hosting framework (see minimal-host repro above). - Not HTTP integrated auth / Negotiate-vs-proxy-407: adding --auth-schemes=basic,digest --auth-server-allowlist= --auth-negotiate-delegate-allowlist= (confirmed present in the affected root process command line) does not prevent the 4625. - Disabling the following features via --disable-features does not prevent it: msLoadOneAuthInBackground, msImplicitSignin, msImplicitSignInNetworkRetry, msOneAuthWAM, msProfileSignIn, msSeamlessWebToBrowserSignIn, msShowSignInIndicator, msWAMSovereigntySignIn, msWAMAdminModeSignIn, msAllowMSAPrtSSOForNonMSAProfile, msAutoToggleMSAPrtSSOForNonMSAProfile, msAutoToggleAADPrtSSOForNonAADProfile, msShowUXForAADPrtSSOForNonAADProfile, msEdgeOSAccountInfoSubstrate, msPrimaryOSAccountInfoCache, msEdgeOSAccountInfoManagerCache, msEdgeReauthAutoRefreshToken, msEdgePasskeysServiceReauth, msQuickAuthToBrowserSignIn, msForceBrowserSignIn, msEnableWebToBrowserSignIn, msEnableAADWebToBrowserSignIn, msEnableProfileAADAccountSSO, msMSNSignInLink, msSendSSODiagnostics, msEdgeSignInAccountPicker, AADSSO, AADWebSSOAllowed (tested individually, in groups, and all combined). - WebView2 policies set under HKLM and HKCU Software\Policies\Microsoft\Edge\WebView2: ImplicitSi

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/8 15:28:52