遠端桌面 NLA 錯誤怎麼修|三層排查法

適用系統:用戶端 Windows 10 / Windows 11;主機 Windows 10 / 11 專業版以上、Windows Server 2016 以上(家用版不提供遠端桌面主機端)
權限需求:主機端需系統管理員;網域環境另需能查詢網域控制站,或請 IT 協助
需要工具:事件檢視器(eventvwr.msc)、PowerShell(系統管理員)、群組原則結果 gpresult、psping、登錄檔編輯器(僅最後手段才用)
預計耗時:約 30–60 分鐘,網域環境需併同 IT 排查

🔍 症狀描述與錯誤訊息

遠端桌面連線的「驗證錯誤」很容易被當成同一種毛病,實際上訊息文字不一樣,背後的層級就完全不同。你會看到的通常是下列三種其中之一:前兩種都指向認證層(CredSSP 被封鎖),第三種指向帳號層(權限不足);網路層通常沒有專屬訊息,而是在前兩層都排除、或連錯誤訊息都拿不到時才輪到它。請以訊息文字本身作為分辨依據,不要用「什麼時候跳出來」來判斷。把訊息原文抄下來,是整個排查最省時間的一步——尤其網域環境裡,錯誤訊息往往是你唯一能拿到的線索。

發生驗證錯誤。
要求的函式不受支援。
遠端電腦:<主機名稱>
這可能是因為 CredSSP 加密 Oracle 補救。
(英文原文:An authentication error has occurred. The function requested is not supported. This could be due to CredSSP encryption oracle remediation.)

發生驗證錯誤。
提供給函式的權杖無效。
(英文原文:An authentication error has occurred. The token supplied to the function is invalid.)

遠端桌面連線:
系統管理員已限制您可以使用的登入類型(網路或互動)。如需協助,請洽詢您的系統管理員或技術支援人員。
(英文原文:The system administrator has restricted the type of logon (network or interactive) that you may use.)

依微軟官方文件,第一與第二種都屬於 CredSSP 加密 Oracle 補救造成的封鎖,但兩者對應的情境不同:「提供給函式的權杖無效」出自未修補、且早於 Windows 8.1 與 Windows Server 2012 R2 的舊用戶端,對上設為「強制更新的用戶端」的伺服器時就會看到它;「要求的函式不受支援」則是已修補的 Windows 8.1 / Server 2012 R2 以後用戶端被封鎖時的訊息。2018 年 4 月 17 日的遠端桌面用戶端更新(KB4093120)做的事,是替後者加強訊息內容——裝了之後才會多出「遠端電腦:<主機名稱>」與「這可能是因為 CredSSP 加密 Oracle 補救」這兩行說明,讓你一眼看出問題出在哪。第三種則跟 CredSSP 無關,是帳號層的權限問題。

🔎 問題根因

NLA(Network Level Authentication,網路層級驗證)的設計意圖是「先驗身分、再建工作階段」:傳統 RDP 是先幫你開一個登入畫面、再讓你輸入帳密,等於任何人都能逼主機配置一個工作階段;NLA 把驗證提前到連線建立之前,主機在確認你是誰之前只配置有限資源,依微軟說法有助於降低阻斷服務攻擊與未授權存取的風險。代價是驗證動作被搬到更早、更沒有容錯空間的位置——這個階段任何一個環節談不攏,你拿到的都只是一行「驗證錯誤」,而不是「密碼錯誤」或「找不到網域控制站」這種有指向性的訊息。

具體來說,NLA 的失敗集中在三層。帳號層:你確實輸入了正確的帳密,但你不在遠端桌面使用者群組裡,或該群組沒有「從網路存取這台電腦」的使用者權限指派——微軟文件明確指出這正是「系統管理員已限制您可以使用的登入類型」的成因。認證層:NLA 透過 CredSSP 傳遞憑證,而更新後的 CredSSP 會協商共同的協定版本(官方事件訊息原文即為 failed to negotiate a common protocol version),兩端修補狀態與原則設定只要落在互斥組合,連線就會被直接封鎖。網路層:NLA 需要真的完成一次驗證,網域環境下代表主機必須連得到網域控制站;DC 離線、被防火牆擋住、或電腦帳戶的安全通道有問題,即使主機本身活得好好的,NLA 一樣過不了。

🔬 底層機制:這個錯誤訊號從哪裡來?

要看懂錯誤訊息,得先知道 NLA 這條驗證鏈實際經過哪些元件。用戶端發起 RDP 連線後,在工作階段建立之前,雙方先透過 CredSSP(Credential Security Support Provider,憑證安全性支援提供者)這個驗證提供者交換憑證。CredSSP 本身不是驗證協定,它是替其他應用程式處理驗證請求的載體——微軟的說法是「an authentication provider that processes authentication requests for other applications」,它底下實際仍是走 Kerberos 或 NTLM,外面再包一層 TLS 保護。所以 NLA 失敗時,壞掉的可能是 TLS 那層(憑證、安全性層設定)、CredSSP 版本協商那層,也可能是最底下的 Kerberos/NTLM 那層(網域可達性、時間偏差、電腦帳戶信任)。

CVE-2018-0886 這個漏洞就出在 CredSSP 驗證請求的驗證方式:攻擊者可以中繼使用者憑證、在目標系統上執行程式碼。微軟 2018 年 3 月 13 日起分批釋出更新修正,並新增了「加密 Oracle 補救」(Encryption Oracle Remediation)這個群組原則,用來控制「要不要允許退回舊版不安全的 CredSSP」。原則有三檔:強制更新的用戶端(登錄值 0)、已緩解(1)、易受攻擊(2)。2018 年 5 月 8 日的更新把預設值從「易受攻擊」改成「已緩解」——這就是為什麼很多人是在系統更新之後才突然連不上:設定並沒有人動過,是預設值變了。

依官方互通性矩陣,被封鎖的組合只有兩種:未修補的用戶端對上設為「強制更新的用戶端」的伺服器,以及已修補且設為「強制更新的用戶端」或「已緩解」的用戶端對上未修補的伺服器。後者也是最常見的一種組合——你的 Windows 11 每個月都在更新,而角落那台好幾年沒重開機的主機沒有;或是主機裝了更新但沒重新開機,因為官方明講「加密 Oracle 補救的任何變更都需要重新開機」。

判斷有沒有踩到這條,不必猜。已修補的 Windows 用戶端在被封鎖時會在系統記錄檔寫下一筆事件:事件識別碼 6041,來源 LSA (LsaSrv),訊息內容為「A CredSSP authentication to *<hostname>* failed to negotiate a common protocol version. The remote host offered version *<Protocol Version>* which is not permitted by Encryption Oracle Remediation.」看到這筆,你就不用再懷疑帳號或網路了。不熟事件檢視器篩選的話,可以先看用事件檢視器讀懂當機紀錄那篇的操作方式,篩選條件換成「系統」記錄檔與來源 LsaSrv 即可。

遠端桌面 NLA 錯誤四步排查流程圖:帳號層、認證層、網路層,最後才是暫時關閉 NLA

🛠️ 解決方案

⚠️ 執行前務必詳讀:本文方法三與方法五涉及群組原則與登錄檔變更,且會降低遠端桌面的安全性。動手前先備份登錄檔,並確認你有實體或其他管道能接觸這台電腦——遠端把 NLA 設錯,可能讓你連不回去。登錄檔備份步驟見Windows 11 登錄檔備份與還原完整教學。

🛑 停止條件清單(符合任一,請勿繼續,改找 IT 或原廠):
– 這台是公司或學校管控的電腦,而你沒有 IT 授權
– 你不確定主機端的 Windows 版本或版次
– 你沒有做過登錄檔備份或系統還原點
– 主機在網際網路上直接暴露 3389 連接埠(此時關閉 NLA 等同開門)
– 指令輸出與本文預期不符,或你看不懂輸出代表什麼
– 你只有遠端這一條路能接觸這台電腦,沒有實體或帶外管理備援

方法一:先用唯讀查詢分辨是哪一層(必做,零風險)

不要急著改設定。先在主機端用系統管理員身分開 PowerShell,把目前狀態讀出來——以下全是唯讀查詢,不會改動任何東西:

# 讀取遠端桌面接聽器的安全性設定(唯讀,不修改)
Get-CimInstance -Namespace root\CIMv2\TerminalServices -ClassName Win32_TSGeneralSetting |
    Select-Object TerminalName, UserAuthenticationRequired, SecurityLayer,
                  PolicySourceUserAuthenticationRequired, PolicySourceSecurityLayer

三個欄位要這樣讀:

欄位	值	意義
`UserAuthenticationRequired`	0	NLA 未啟用
`UserAuthenticationRequired`	1	NLA 已啟用(連線時要求驗證)
`SecurityLayer`	1 / 2 / 3	分別為 RDP 安全性層 / 交涉 / SSL(TLS)
`PolicySource*`	0 / 1 / 2	分別為伺服器設定 / 群組原則 / 預設值

**PolicySource* 這兩欄是本文最重要的一個判斷點,務必特別拉出來看:如果它回 1(群組原則)**,代表這台的設定是 GPO 壓下來的——你在系統內容裡把勾選改掉、或直接改登錄檔,下次原則重新套用就會被蓋回去,你會誤以為「改了沒用」。這時正確做法是去查是哪一條 GPO:

# 產生群組原則結果報表,再用瀏覽器開啟 C:\gpresult.html 檢視
gpresult /H C:\gpresult.html

報表裡到 電腦設定\系統管理範本\Windows 元件\遠端桌面服務\遠端桌面工作階段主機\安全性 底下,看「Require user authentication for remote connections by using Network Level Authentication」與「Require use of specific security layer for remote (RDP) connections」兩條的狀態與 Winning GPO,才知道要找誰改。

再到用戶端的事件檢視器 →Windows 記錄檔 → 系統,篩選來源 LsaSrv、事件識別碼 6041。有這筆就是 CredSSP 版本協商被封鎖(跳方法三);沒有這筆而錯誤訊息是「已限制登入類型」,就是帳號層(方法二)。

方法二:帳號層——群組成員資格與使用者權限指派

「系統管理員已限制您可以使用的登入類型(網路或互動)」這句話幾乎就是明示:NLA 要求驗證,但這個帳號不具備以網路方式登入這台電腦的資格。官方給的兩個成因與對應處置是:

使用者不在「Remote Desktop Users」群組——把帳號加進去即可。單機環境:compmgmt.msc →本機使用者和群組 →群組 → Remote Desktop Users。
「Remote Desktop Users」群組沒有被指派「從網路存取這台電腦」(Access this computer from the network)使用者權限——這在有套 GPO 的環境特別常見。

第二點的檢查路徑:開啟群組原則物件編輯器,連到該電腦的本機原則,到 電腦設定\Windows 設定\安全性設定\本機原則\使用者權限指派,找「從網路存取這台電腦」,看清單裡有沒有 Remote Desktop Users 或其上層群組。微軟文件特別提醒:這項權限的預設成員包含 Everyone,如果你的環境用 GPO 把 Everyone 移掉了(很多資安基準都會這麼做),就必須另外把 Remote Desktop Users 加回清單;若清單中已經沒有任何涵蓋該帳號的群組,NLA 環境下該使用者就會被擋在門外。多台電腦請用 GPO 統一設定,不要一台一台改。

順帶一提:如果你是先前存過錯誤的帳密、現在怎麼輸入都不對,問題可能出在快取的認證項目而不是權限。清除方式見Windows 認證管理員完整教學。

方法三:認證層——CredSSP 加密 Oracle 補救

確認是 CredSSP 封鎖(事件 6041 或訊息含「CredSSP 加密 Oracle 補救」)之後,唯一的正解是把兩端更新裝齊並重新開機,而不是去改原則。官方文件的原話就是「To resolve this issue, update and restart all systems.」把用戶端與主機端的 Windows 累積更新都裝到最新、兩台都重開機,多數案例到這裡就結束了。

真的有無法立即更新的主機(例如受廠商合約綁定的設備),官方列出的暫時性作法有兩條路,兩條都會降低安全性:

路徑 A:把用戶端的加密 Oracle 補救原則調回「易受攻擊」。群組原則位置是 電腦設定\系統管理範本\系統\認證委派\加密 Oracle 補救(Computer Configuration → Administrative Templates → System → Credentials Delegation → Encryption Oracle Remediation)。三個選項與對應登錄值為:

原則設定	登錄值	用戶端行為	伺服器行為
強制更新的用戶端	0	不允許退回不安全版本	不接受未修補的用戶端
已緩解(2018-05-08 起的預設)	1	不允許退回不安全版本	接受未修補的用戶端
易受攻擊	2	允許退回不安全版本,會使遠端伺服器暴露於攻擊	接受未修補的用戶端

對應的登錄機碼是 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters,值名稱 AllowEncryptionOracle,型別 DWORD。動這個機碼之前,先把它匯出存檔:

# 變更 AllowEncryptionOracle 前,先匯出該機碼作為回退依據
$dir = "C:\Users\Public\Documents\TedTechBackup"
if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir | Out-Null }
$stamp = Get-Date -Format "yyyyMMdd_HHmmss"
& reg.exe export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" (Join-Path $dir "CredSSP_Parameters_$stamp.reg") /y

(該機碼不存在時 reg export 會回錯誤,代表這台從未設過此原則,回退時直接刪除你新增的值即可。)官方明載:加密 Oracle 補救的任何變更都需要重新開機。

路徑 B:在主機端暫時放寬遠端桌面的安全性層與 NLA 要求。群組原則位置 電腦設定\系統管理範本\Windows 元件\遠端桌面服務\遠端桌面工作階段主機\安全性,把「Require use of specific security layer for remote (RDP) connections」設為已啟用並選 RDP、把「Require user authentication for remote connections by using Network Level Authentication」設為已停用。

⚠️ 微軟對路徑 B 的原文警告是:「Changing these group policies reduces your deployment’s security. We recommend you only use them temporarily, if at all.」——變更這些群組原則會降低你部署環境的安全性,建議只在必要時暫時使用。這句話請當真:這兩條路都是把你留在比原本更不安全的狀態,更新裝完就該立刻還原。

方法四:網路層——可達性、網域與接聽器

前兩層都排除了,就往下查。這一層的動作大多是唯讀檢查,順序建議如下:

服務有沒有在跑:主機端與用戶端都要有 Remote Desktop Services (TermService) 與 Remote Desktop Services UserMode Port Redirector (UmRdpService) 兩個服務執行中。
接聽器活著嗎:主機端執行 qwinsta,清單裡要看到 rdp-tcp 且狀態為 Listen。
連接埠有沒有被搶:netstat -ano | find "3389" 看有沒有東西在接聽 3389,再用 tasklist /svc 對照 PID,確認佔用者是遠端桌面服務而不是別的程式。
RDP 有沒有被關掉或被 GPO 擋掉:查 HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server 的 fDenyTSConnections,0 代表 RDP 已啟用、1 代表停用;若你改成 0 之後又自己變回 1,那就是 GPO 在蓋,回頭用 gpresult 找「Allow users to connect remotely by using Remote Desktop Services」的 Winning GPO。
防火牆通不通:從另一台正常的電腦用 psping -accepteula <主機 IP>:3389 測試;(0% loss) 代表通,The remote computer refused the network connection 或 (100% loss) 代表不通,接著查中間的防火牆與主機端的 Windows 防火牆規則。
網域環境的額外三件事:NLA 需要能完成真正的驗證,所以主機必須連得到網域控制站;若使用 Windows Defender Remote Credential Guard 又搭配兩台以上做負載平衡的 RD 連線代理人,官方明載會因為 Remote Credential Guard 走 Kerberos 且限制 NTLM、而負載平衡的連線代理人無法支援 Kerberos 作業而登不進去,此時只能停用 Remote Credential Guard;另外若你用的是會讀取 AD 使用者物件的自訂連線程式,可能會撞到 Windows Server 2016 起遠端連線管理員不再查詢 AD DS 的行為改變,需要另行以 fQueryUserConfigFromDC 開啟舊行為。
接聽器憑證壞掉:若上述都正常仍連不上,可用憑證 MMC(電腦帳戶)到「遠端桌面」底下刪除 RDP 自我簽署憑證,重新啟動遠端桌面服務讓它重建;沒重建的話再檢查 C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys 的權限是否為 Builtin\Administrators 完全控制、Everyone 讀取與寫入。

方法五:最後手段——暫時關閉 NLA

這是最後手段,不是快速解法。關閉 NLA 會讓主機在驗證你的身分之前就配置工作階段,等於把 NLA 原本擋掉的曝險又打開;若這台主機的 3389 對網際網路開放,關閉 NLA 之後請視為隨時會被打進來。只有在同時滿足「純內網」「有實體或帶外管理備援」「已排定時間裝更新還原」三個前提時才考慮。

操作上請優先用 GUI 而不是登錄檔:sysdm.cpl →遠端 →取消勾選「只允許執行採用網路層級驗證之遠端桌面的電腦連線」。改之前,先把方法一那段唯讀查詢的輸出存成檔案:

# 變更前先把目前設定存檔,作為之後還原的依據
$stamp = Get-Date -Format "yyyyMMdd_HHmmss"
$dir = "C:\Users\Public\Documents\TedTechBackup"
if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir | Out-Null }
Get-CimInstance -Namespace root\CIMv2\TerminalServices -ClassName Win32_TSGeneralSetting |
    Select-Object TerminalName, UserAuthenticationRequired, SecurityLayer,
                  PolicySourceUserAuthenticationRequired, PolicySourceSecurityLayer |
    Export-Csv -Path (Join-Path $dir "TSGeneralSetting_$stamp.csv") -NoTypeInformation -Encoding UTF8

⚠️ 一個很容易踩的坑:Win32_TSGeneralSetting 的 SecurityLayer「屬性值」是 1 = RDP 安全性層、2 = 交涉、3 = SSL,但同一個類別的 SetSecurityLayer「方法參數」卻是 0 = RDP 安全性層、1 = 交涉、2 = SSL——兩者差 1。照著屬性值餵給方法,你會把設定改成完全不同的東西還以為自己設對了。這兩組數字都寫在微軟官方的 Win32_TSGeneralSetting 文件裡,不是坊間傳說,動手前請務必回頭核對一次。

✅ 驗證修復結果

改完不要只看「連得上了」就收工,那可能只是暫時繞過。請逐項確認:

重新開機後仍然連得上:CredSSP 相關變更需重新開機才生效,反過來說,沒重開機就成功的「修好」不算數。
事件 6041 不再新增:回到用戶端事件檢視器,篩選來源 LsaSrv、識別碼 6041,確認時間戳沒有新的一筆。
設定值與你的預期一致:重跑方法一的唯讀查詢,比對 UserAuthenticationRequired 與 SecurityLayer 是不是你要的狀態,並確認 PolicySource* 沒有意外變成 1(群組原則)——如果變成 1,代表你改的那層其實被 GPO 接手了。
換一個帳號再連一次:方法二那類權限問題常常只影響部分帳號,用系統管理員帳號測成功不代表一般使用者也能連。
如果你走了方法三或方法五:把「等待裝更新並還原設定」排進行事曆,不要讓「暫時」變成永久。

🔙 萬一翻車:回退步驟

情境一:改完之後完全連不上遠端桌面

這是最常見的翻車方式,通常發生在遠端改設定把自己鎖在門外。處理原則:先用實體或帶外管理接觸這台電腦,再依你當初改了什麼逐項還原。

改過群組原則:把該條原則設回「尚未設定」(不是設成另一個值),然後執行 gpupdate /force 並重新開機。設回「尚未設定」才會真正交還給系統預設,設成別的值只是換一種硬編碼。
改過登錄檔:用你變更前匯出的 .reg 檔還原,例如 reg import "C:\Users\Public\Documents\TedTechBackup\你的備份檔.reg",然後重新開機。

情境二:要把 NLA 設回原狀,但不確定原本是什麼值

請以你在方法五存下的那份 CSV 為準還原,不要照抄任何文章給的固定值(包括本文)。原因有兩個:微軟並未發布各 Windows 版本、版次與版本別的預設值對照表,任何文章給的「標準值」都只是該作者當下那台機器的狀態;而且你這台的值很可能早就被環境裡的 GPO 或資安基準改過。硬寫一個固定值回去,對某些機器是還原、對另一些機器則是把設定改成從來沒有過的狀態——那不叫回退,那叫又改了一次。

如果 CSV 也沒存,退而求其次的安全作法是:把對應的群組原則設回「尚未設定」、把你手動新增的登錄值刪除(而不是改成 0 或 1),讓系統回到自己的預設,再重新開機確認。

情境三:還原之後仍然連不上

先確認一件事:還原之後仍然故障,不代表原本的故障就是你改壞的,也不能直接推給網路卡、路由器或第三方軟體。正確做法是回到方法一,重新做一次唯讀查詢與事件檢視,把三層重新判斷一遍——很可能你當初判錯了層,一開始的病根還在那裡。若查到最後仍無法定位,把事件 6041 的完整訊息、gpresult 報表與方法一的查詢輸出整理好,再去找 IT 或微軟支援,比自己繼續試設定有效率得多。

💡 總結:預防再次發生

站長我處理這類案子的順序永遠是「先讀、後改」:任何 NLA 錯誤,先花五分鐘把事件檢視器與那段唯讀 WMI 查詢跑完,再決定要不要動設定。理由很現實——遠端桌面的三層問題長得幾乎一模一樣,但改錯層的代價差很多:帳號層改錯只是白忙,認證層與網路層改錯,你可能連不回去。而 PolicySourceUserAuthenticationRequired 這個欄位之所以值得你記起來,是因為它一秒就能回答「這台的設定到底是誰在管」;不看這欄就直接改本機設定,是這類問題最常見也最讓人抓狂的時間浪費:改完當下有效,重開機或原則重新套用之後又壞,反覆好幾輪才發現一直在跟 GPO 拔河。

長期預防有三件事值得做。第一,把更新裝齊並確實重開機:CredSSP 這類問題的正解永遠是更新,原則放寬只是止血。第二,變更前先把現況存檔:一份 CSV 或一個 .reg 匯出檔,就能讓你之後的回退是「還原」而不是「猜一個值」。第三,別把 3389 直接暴露在網際網路上:遠端桌面該走 VPN 或遠端桌面閘道,一旦你哪天真的必須暫時關掉 NLA,內網與外網的風險差距是天差地遠。

❓ 常見問題

Q:一定要關閉 NLA 才能連上嗎?

不用,而且大多數情況不該關。關 NLA 只解決「認證層談不攏」這一種情形,對帳號層與網路層問題完全無效——你會關掉一層防護卻還是連不上。先用方法一分辨層級,多數案例的正解是裝更新加重新開機。

Q:為什麼我明明是系統管理員,卻跳「已限制您可以使用的登入類型」?

這句話的判斷依據不是你有沒有管理員身分,而是「遠端桌面使用者」群組成員資格與「從網路存取這台電腦」的使用者權限指派。有套資安基準 GPO 的環境常把預設的 Everyone 從該權限清單移除,若沒有補上遠端桌面使用者群組,即使是管理員帳號也可能被擋。

Q:改了設定但重開機後又變回去,是不是壞掉了?

不是壞掉,是被群組原則覆蓋。跑方法一的唯讀查詢看 PolicySourceUserAuthenticationRequired,如果是 1 就代表由群組原則管控,要用 gpresult /H 找出 Winning GPO 從原則層面改,改本機設定沒有用。

Q:修完之後又復發怎麼辦?

先判斷復發的是不是同一層:重跑一次方法一的查詢與事件 6041 檢查。若又是 CredSSP 封鎖,通常代表當初只放寬了原則、更新一直沒補齊,或某一端裝了更新卻沒重新開機;若變成帳號層錯誤,多半是新的 GPO 或群組異動把權限收走了。

Q:家用版 Windows 也適用這篇嗎?

用戶端可以,主機端不行。Windows 家用版不提供遠端桌面主機功能,無法作為被連線的一方;本文主機端的設定與檢查,請在專業版以上或 Windows Server 上執行。

🔗 延伸閱讀

Windows WMI 壞掉怎麼修?Repository 驗證與修復——方法一的 WMI 查詢若直接報錯,先修 WMI 再回來排查
Win10/Win11 防火牆白名單設定方法——方法四確認 3389 被擋時的處理
Windows 資源監視器完整教學——比對連接埠與行程佔用的另一條路
Win10/Win11 如何用 Command 開啟控制台工具——sysdm.cpl、compmgmt.msc 這類指令的完整清單
Windows 工作排程器教學——把「暫時放寬設定」排成定時提醒還原

📎 參考資料來源

📖 第一級|廠商官方:

CredSSP updates for CVE-2018-0886(KB4093492) — 2026-08-18 查證
User can’t authenticate or must authenticate twice – Microsoft Learn — 2026-08-18 查證
General Remote Desktop connection troubleshooting – Microsoft Learn — 2026-08-18 查證
Win32_TSGeneralSetting class – Microsoft Learn — 2026-08-18 查證
SetSecurityLayer method of the Win32_TSGeneralSetting class — 2026-08-18 查證
Configure Network Level Authentication for Remote Desktop Services Connections) — 2026-08-18 查證
How to enable Remote Desktop – Microsoft Learn — 2026-08-18 查證

⚠️ 本文核心事實以第一級為準,第二級為補充。

📅 本文查證戳記:2026-08-18 依微軟官方文件撰寫,非第一手實機測試。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。