Lỗi NLA trong RDP: Nguyên nhân, Cách khắc phục & Thực tiễn tốt nhất

Giới thiệu

Xác thực cấp mạng (NLA) là một biện pháp kiểm soát an ninh cốt lõi cho Giao thức Desktop từ xa, ngăn chặn người dùng không được xác thực trước khi một phiên đầy đủ được tạo ra. Tuy nhiên, khi NLA thất bại, các nhóm CNTT phải đối mặt với việc đăng nhập bị chặn, thông báo lỗi mơ hồ và người dùng cuối thất vọng không thể truy cập vào các máy chủ quan trọng. Hướng dẫn này giải thích NLA là gì, tại sao những lỗi này xảy ra và cách khắc phục và giải quyết các vấn đề NLA một cách có hệ thống mà không làm yếu đi tư thế an ninh RDP của bạn.

NLA trong RDP là gì?

Xác thực cấp mạng là một cải tiến bảo mật RDP được giới thiệu cùng với Windows Vista và Windows Server 2008. Thay vì xây dựng phiên làm việc từ xa đầy đủ và sau đó yêu cầu thông tin xác thực, NLA yêu cầu người dùng xác thực trước. Chỉ sau khi xác thực thành công, ngăn xếp RDP mới tạo phiên đồ họa.

NLA dựa vào CredSSP (Nhà cung cấp Hỗ trợ Bảo mật Thông tin Đăng nhập) để truyền đạt an toàn thông tin đăng nhập của người dùng đến hệ thống mục tiêu. Trong các môi trường đã tham gia miền, CredSSP giao tiếp với Active Directory để xác thực tài khoản trước khi phiên làm việc được thiết lập. Trên các máy chủ độc lập hoặc nhóm làm việc, CredSSP xác thực các tài khoản cục bộ được cấu hình cho đăng nhập từ xa.

Lợi ích chính của NLA bao gồm:

• Giảm thiểu cửa sổ cho các cuộc tấn công brute-force và từ chối dịch vụ vào các điểm cuối RDP bị lộ.
• Kích hoạt đăng nhập một lần (SSO) cho người dùng miền, cải thiện trải nghiệm người dùng
• Cải thiện hiệu suất bằng cách thực hiện xác thực trước khi tạo phiên

Tuy nhiên, NLA nhạy cảm với các phiên bản hệ điều hành, bản vá, TLS cấu hình và tình trạng miền. Khi bất kỳ điều kiện tiên quyết nào trong số đó không đạt, NLA có thể chặn hoàn toàn các kết nối hợp lệ.

Các triệu chứng phổ biến của lỗi NLA trong RDP là gì?

Các vấn đề liên quan đến NLA thường xuất hiện với các thông điệp tương tự, bất kể nguyên nhân cơ bản. Bạn có thể đang gặp phải một vấn đề NLA nếu bạn gặp:

• Máy tính từ xa yêu cầu Xác thực Cấp Mạng (NLA), nhưng máy tính của bạn không hỗ trợ điều này.
• Lỗi xác thực đã xảy ra. Chức năng yêu cầu không được hỗ trợ.
• Lỗi khắc phục oracle mã hóa CredSSP.
• Thông tin đăng nhập của bạn không hoạt động.
• Thời gian chờ hoặc ngắt kết nối đột ngột trong quá trình bắt tay RDP ban đầu hoặc ngay sau khi nhập thông tin xác thực

Các triệu chứng này có thể ảnh hưởng đến cả máy chủ đã tham gia miền và máy chủ độc lập. Trong thực tế, chúng thường xuất phát từ các chính sách bảo mật không khớp, việc chặn truy cập vào bộ điều khiển miền, hoặc các thành phần RDP lỗi thời ở một trong hai bên.

Nguyên nhân của lỗi NLA trong RDP là gì?

Hiểu các nguyên nhân gốc rễ phổ biến giúp bạn khắc phục sự cố nhanh chóng và tránh các giải pháp tạm thời rủi ro như vô hiệu hóa NLA vĩnh viễn.

• Không tương thích giữa hệ điều hành máy khách hoặc máy chủ
• Máy chủ miền không thể truy cập
• Lỗi không khớp bản vá CredSSP
• Cấu hình sai mã hóa TLS hoặc RDP
• Xung đột Chính sách Nhóm hoặc Registry
• Hồ sơ người dùng hoặc thông tin xác thực bị hỏng
• Kịch bản Nhóm làm việc và Không thuộc miền

Không tương thích giữa hệ điều hành máy khách hoặc máy chủ

Các phiên bản Windows cũ hơn hoặc các khách hàng RDP của bên thứ ba có thể không hoàn toàn hỗ trợ NLA hoặc hành vi CredSSP hiện đại. Ví dụ, các phiên bản Windows XP cũ hoặc các bản dựng Vista sớm không thể kết nối với các máy chủ yêu cầu NLA mà không có các bản cập nhật cụ thể. Ngay cả trên các hệ thống được hỗ trợ, các tệp nhị phân khách RDP lỗi thời có thể gây ra lỗi "máy tính của bạn không hỗ trợ NLA" mặc dù hệ điều hành về mặt lý thuyết hỗ trợ nó.

Máy chủ miền không thể truy cập

Trong một môi trường đã tham gia miền, NLA phụ thuộc vào việc kết nối với một bộ điều khiển miền để xác thực thông tin đăng nhập và duy trì kênh bảo mật của máy. Nếu bộ điều khiển miền ngoại tuyến, bị chặn bởi một tường lửa , hoặc có vấn đề về độ tin cậy, xác thực NLA có thể thất bại mặc dù máy chủ vẫn hoạt động. Bạn sẽ thường thấy các lỗi đề cập đến khả năng kết nối với bộ điều khiển miền hoặc các thông báo “đã xảy ra lỗi xác thực” chung.

Lỗi không khớp bản vá CredSSP

Bắt đầu từ các bản cập nhật "Khắc phục Oracle Mã hóa" năm 2018, CredSSP trở nên nghiêm ngặt hơn về cách bảo vệ thông tin xác thực. Nếu một máy khách có bản cập nhật nhưng máy chủ thì không (hoặc ngược lại), hai điểm cuối có thể không đồng ý về một cấu hình an toàn. Sự không khớp này có thể tạo ra lỗi "khắc phục oracle mã hóa CredSSP" và ngăn chặn các lần đăng nhập NLA cho đến khi cả hai bên được vá hoặc Chính sách Nhóm được điều chỉnh.

Cấu hình sai mã hóa TLS hoặc RDP

NLA dựa vào Transport Layer Security (TLS) để bảo vệ việc trao đổi thông tin xác thực. Nếu TLS 1.0/1.1 bị vô hiệu hóa mà không kích hoạt đúng TLS 1.2, hoặc nếu các bộ mã hóa yếu được áp dụng, quá trình bắt tay giữa máy khách và máy chủ có thể thất bại trước khi NLA hoàn tất. Việc tăng cường bảo mật tùy chỉnh, chế độ FIPS, hoặc chứng chỉ cấu hình sai có thể làm hỏng NLA mặc dù RDP tiêu chuẩn không có NLA vẫn có thể hoạt động trong một số điều kiện.

Xung đột Chính sách Nhóm hoặc Registry

Các Đối tượng Chính sách Nhóm (GPO) và chính sách bảo mật cục bộ kiểm soát cách RDP, CredSSP và mã hóa hoạt động. Các chính sách mâu thuẫn hoặc quá nghiêm ngặt có thể áp dụng NLA trong các tình huống mà khách hàng không hỗ trợ hoặc yêu cầu các thuật toán tuân thủ FIPS mà khách hàng của bạn không thể sử dụng. Các ghi đè trong Registry cho SCHANNEL hoặc CredSSP có thể gây ra những bất nhất tương tự, dẫn đến “chức năng được yêu cầu không được hỗ trợ” và các lỗi chung khác.

Hồ sơ người dùng hoặc thông tin xác thực bị hỏng

Thỉnh thoảng, vấn đề chỉ xảy ra với một người dùng hoặc máy tính. Thông tin xác thực được lưu trữ bị hỏng, một sự không đồng nhất Mã định danh bảo mật (SID), hoặc một tệp Default.rdp bị hỏng có thể gây cản trở việc xác thực NLA. Trong những trường hợp này, bạn có thể thấy rằng một người dùng khác có thể đăng nhập từ cùng một thiết bị, hoặc cùng một người dùng có thể đăng nhập từ một máy khách khác, nhưng không thể cả hai cùng lúc.

Kịch bản Nhóm làm việc và Không thuộc miền

NLA giả định một môi trường mà danh tính người dùng có thể được xác thực mạnh mẽ, thường thông qua Active Directory. Trong các hệ thống nhóm làm việc, các tài khoản cục bộ phải được cấu hình cẩn thận và phải có quyền đăng nhập qua Remote Desktop. Nếu NLA được thực thi nhưng không có bộ điều khiển miền nào khả dụng, hoặc cài đặt tài khoản cục bộ không chính xác, bạn có thể thấy các lỗi liên quan đến NLA mặc dù máy chủ có vẻ có thể truy cập được.

Cách khắc phục lỗi NLA trong RDP?

Sử dụng các bước sau theo thứ tự, từ ít xâm lấn đến xâm lấn nhiều nhất. Cách tiếp cận này giúp khôi phục quyền truy cập trong khi vẫn bảo vệ an ninh ở mức có thể.

• Xác nhận hỗ trợ NLA trên máy khách và máy chủ
• Xác minh kết nối với bộ điều khiển miền (nếu có)
• Căn chỉnh mức độ và chính sách của CredSSP Patch
• Kích hoạt và xác thực các giao thức TLS cần thiết
• Xem xét và điều chỉnh Chính sách Nhóm
• Tạm thời vô hiệu hóa NLA để khôi phục quyền truy cập
• Đặt lại cấu hình RDP Client và Mạng

Xác nhận hỗ trợ NLA trên máy khách và máy chủ

Đầu tiên, hãy đảm bảo rằng cả hai điểm cuối đều có khả năng NLA.

• Chạy winver trên cả máy khách và máy chủ để xác nhận chúng là Windows Vista / Windows Server 2008 hoặc mới hơn.
• Đảm bảo rằng các bản cập nhật mới nhất của ứng dụng Remote Desktop được cài đặt (thông qua Windows Update hoặc ứng dụng Microsoft Remote Desktop trên các nền tảng không phải Windows).
• Nếu bạn đang sử dụng các khách hàng RDP của bên thứ ba, hãy xác minh rằng hỗ trợ NLA được tài liệu hóa rõ ràng và được bật trong cài đặt của khách hàng.

Nếu một trong hai bên không hỗ trợ NLA, hãy lên kế hoạch nâng cấp hoặc thay thế thành phần đó thay vì làm yếu đi bảo mật toàn cầu.

Xác minh kết nối với bộ điều khiển miền (nếu có)

Trên các máy đã tham gia miền, xác thực kết nối miền trước khi thay đổi cài đặt RDP.

• Kiểm tra khả năng tiếp cận mạng cơ bản đến các bộ điều khiển miền (ví dụ, ping dc01.yourdomain.com ).
• Sử dụng nltest /dsgetdc:yourdomain.com để xác nhận rằng khách hàng có thể tìm thấy một bộ điều khiển miền.
• Trong PowerShell, chạy Kiểm tra-KênhBảoMậtMáyTính để kiểm tra kênh bảo mật của máy đến miền.

Nếu kênh bảo mật bị hỏng, hãy sửa chữa nó bằng cách:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Sau khi sửa chữa, khởi động lại máy nếu được yêu cầu, sau đó kiểm tra lại NLA. Giải quyết các cấu hình sai DNS, quy tắc tường lửa hoặc vấn đề VPN có thể ngăn chặn truy cập miền một cách không liên tục.

Căn chỉnh mức độ và chính sách của CredSSP Patch

Tiếp theo, xác nhận rằng cả máy khách và máy chủ đều có các bản cập nhật bảo mật hiện tại, đặc biệt là những bản liên quan đến CredSSP.

• Cài đặt tất cả các bản cập nhật quan trọng và bảo mật trên cả hai điểm cuối.
• Kiểm tra xem Chính sách Nhóm có được sử dụng để cấu hình “Khắc phục Oracle Mã hóa” dưới:
  Cấu hình máy tính → Mẫu quản trị → Hệ thống → Ủy quyền thông tin xác thực .

Trong một môi trường thử nghiệm tạm thời, bạn có thể đặt chính sách ở mức giá trị cho phép hơn để xác nhận rằng một cài đặt nghiêm ngặt đang gây ra sự cố. Trong môi trường sản xuất, giải pháp lâu dài nên là đưa tất cả các hệ thống về một mức độ vá lỗi nhất quán thay vì nới lỏng chính sách một cách vĩnh viễn.

Kích hoạt và xác thực các giao thức TLS cần thiết

Đảm bảo rằng TLS 1.2 được hỗ trợ và kích hoạt, vì nhiều môi trường hiện nay đã vô hiệu hóa các phiên bản TLS cũ hơn.

Trên Windows Server, xác minh các cài đặt SCHANNEL trong registry dưới:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Để hỗ trợ khách hàng TLS 1.2, hãy xác nhận rằng:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

"Enabled"=dword:00000001

Bạn có thể cần điều chỉnh các khóa TLS 1.2 phía máy chủ, sau đó khởi động lại máy chủ hoặc ít nhất là Dịch vụ Remote Desktop. Cũng hãy xác nhận rằng chứng chỉ RDP là hợp lệ, được tin cậy và không sử dụng các chữ ký đã lỗi thời.

Xem xét và điều chỉnh Chính sách Nhóm

Chính sách nhóm thường là nơi quy định việc thực thi NLA và cấu hình bảo mật RDP.

Mở gpedit.msc (và đối tượng GPMC tương đương) và điều hướng đến:

Cấu hình máy tính → Cài đặt Windows → Cài đặt bảo mật → Chính sách cục bộ → Tùy chọn bảo mật

Kiểm tra đặc biệt:

• Yêu cầu xác thực người dùng cho các kết nối từ xa bằng cách sử dụng Xác thực Cấp Mạng
• Bất kỳ chính sách nào thực thi các thuật toán tuân thủ FIPS hoặc hạn chế các loại mã hóa

Đảm bảo rằng việc thực thi NLA phù hợp với khả năng của khách hàng của bạn. Nếu bạn nới lỏng một chính sách để khôi phục quyền truy cập, hãy ghi lại sự thay đổi và lên lịch thời gian để khắc phục các vấn đề cơ bản của khách hàng thay vì để các cài đặt yếu hơn tồn tại vô thời hạn.

Tạm thời vô hiệu hóa NLA để khôi phục quyền truy cập

Nếu bạn đã mất toàn bộ quyền truy cập từ xa vào một máy chủ quan trọng, tạm thời tắt NLA có thể là một biện pháp cuối cùng cần thiết.

Bạn có thể:

• Khởi động vào Chế độ An toàn với Mạng và điều chỉnh cài đặt Remote Desktop, hoặc
• Khởi động bằng phương tiện phục hồi, tải hive hệ thống và chỉnh sửa khóa RDP-Tcp trong registry.

Cài đặt:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

"UserAuthentication"=dword:00000000

Điều này vô hiệu hóa NLA cho trình nghe RDP. Khi bạn khôi phục quyền truy cập, hãy khắc phục nguyên nhân gốc rễ (kết nối miền, bản vá, TLS hoặc chính sách), sau đó kích hoạt lại NLA bằng cách khôi phục giá trị về 1. Việc giữ NLA bị vô hiệu hóa trong thời gian dài sẽ làm tăng đáng kể khả năng bị tấn công bằng brute-force và khai thác.

Đặt lại cấu hình RDP Client và Mạng

Nếu các sự cố NLA dường như chỉ xảy ra trên một thiết bị khách hàng cụ thể, hãy thực hiện một lần đặt lại cục bộ trước khi thay đổi chính sách máy chủ.

• Xóa đi Default.rdp tệp trong %userprofile%\Documents để xóa cài đặt đã lưu trong bộ nhớ cache.
• Xóa và thêm lại bất kỳ thông tin đăng nhập đã lưu nào trong Trình quản lý thông tin đăng nhập của Windows.
• Xác nhận rằng TCP 3389 (hoặc cổng RDP tùy chỉnh của bạn) được phép qua các tường lửa cục bộ và các thiết bị mạng trung gian.
• Kiểm tra từ một khách hàng khác trên cùng một mạng để xác định xem vấn đề có phải là đặc thù của khách hàng hay là vấn đề toàn cầu hơn.

Bước vệ sinh đơn giản này thường giải quyết các vấn đề với thông tin xác thực bị hỏng trong bộ nhớ cache hoặc các tùy chọn hiển thị và bảo mật không được áp dụng đúng trong ứng dụng RDP.

Các phương pháp tốt nhất để tránh lỗi NLA trong tương lai là gì?

Khi vấn đề ngay lập tức được khắc phục, hãy củng cố môi trường của bạn để NLA vẫn an toàn và đáng tin cậy.

• Giữ cho Hệ điều hành và Khách hàng RDP được Cập nhật
• Giám sát Tình trạng Miền và Danh tính
• Chuẩn hóa chính sách RDP và NLA thông qua GPO
• Kích hoạt Nhật ký Sự kiện và Giám sát Bảo mật
• Cô lập RDP phía sau các điểm truy cập an toàn

Giữ cho Hệ điều hành và Khách hàng RDP được Cập nhật

Duy trì một nhịp độ vá lỗi tiêu chuẩn cho cả máy chủ và điểm cuối. Đồng bộ hóa các phiên bản Windows được hỗ trợ và tránh để lại các máy khách cũ, không được vá trong môi trường sản xuất. Các tiêu chuẩn cập nhật nhất quán giảm thiểu sự không khớp giữa CredSSP và TLS thường gây ra sự cố NLA.

Giám sát Tình trạng Miền và Danh tính

Đối với các hệ thống đã tham gia miền, hãy coi sức khỏe của bộ điều khiển miền là một phần của ngăn xếp RDP của bạn. Sử dụng các công cụ như dcdiag , repadmin , và nhật ký sự kiện của bộ điều khiển miền để phát hiện sớm các vấn đề về sao chép hoặc DNS. Các lỗi miền không liên tục có thể xuất hiện dưới dạng các vấn đề RDP và NLA lâu trước khi người dùng nhận thấy các triệu chứng khác.

Chuẩn hóa chính sách RDP và NLA thông qua GPO

Xác định của bạn RDP mã hóa, thực thi NLA và chính sách CredSSP một cách tập trung. Áp dụng chúng theo OU hoặc nhóm bảo mật dựa trên vai trò thiết bị, chẳng hạn như máy chủ sản xuất so với phòng thí nghiệm thử nghiệm. Chuẩn hóa giảm thiểu sự lệch cấu hình và giúp việc khắc phục sự cố nhanh hơn nhiều khi có vấn đề phát sinh.

Kích hoạt Nhật ký Sự kiện và Giám sát Bảo mật

Giám sát Trình xem sự kiện trên các máy chủ RDP, đặc biệt là:

• Windows Logs → Bảo mật
• Nhật ký Windows → Hệ thống
• Nhật ký Ứng dụng và Dịch vụ → Microsoft → Windows → TerminalServices

Liên kết các lần đăng nhập thất bại lặp lại, lỗi bắt tay TLS hoặc lỗi CredSSP với SIEM của bạn khi có thể. Việc giám sát này giúp phân biệt giữa các vấn đề cấu hình và các cuộc tấn công đang diễn ra.

Cô lập RDP phía sau các điểm truy cập an toàn

Ngay cả với NLA, việc phơi bày RDP trực tiếp ra internet là rủi ro cao. Đặt RDP sau một cổng an toàn, VPN hoặc proxy kiểu ZTNA. Thêm MFA khi có thể. Các công cụ như TSplus Advanced Security có thể hạn chế thêm nơi, thời gian và cách người dùng kết nối, giảm khả năng xảy ra các sự cố liên quan đến NLA đến máy chủ.

Củng cố bảo mật RDP với TSplus Advanced Security

NLA chỉ giải quyết một phần của phương trình rủi ro RDP. TSplus Advanced Security thêm các lớp bảo vệ bổ sung xung quanh các máy chủ Windows và máy tính để bàn từ xa của bạn mà không cần sự phức tạp của các ngăn xếp VDI hoàn chỉnh. Các tính năng như bảo vệ chống tấn công brute-force động, hạn chế theo IP và quốc gia, chính sách giờ làm việc và quy tắc truy cập theo cấp độ ứng dụng giúp giữ cho kẻ tấn công bên ngoài trong khi người dùng hợp pháp vẫn duy trì hiệu suất làm việc.

Đối với các tổ chức dựa vào RDP nhưng muốn có các biện pháp bảo mật mạnh mẽ và đơn giản hơn, việc kết hợp NLA với TSplus Advanced Security cung cấp một cách thực tiễn để tăng cường bảo mật truy cập từ xa và giảm tải công việc phản ứng sự cố.

Kết luận

Lỗi NLA trong RDP rất khó chịu, đặc biệt khi chúng xuất hiện mà không có thay đổi rõ ràng nào trong môi trường. Trên thực tế, chúng gần như luôn chỉ ra các vấn đề cụ thể trong các phiên bản hệ điều hành, kết nối miền, vá CredSSP, cấu hình TLS hoặc chính sách bảo mật. Bằng cách làm việc qua một danh sách kiểm tra có cấu trúc, bạn có thể khôi phục quyền truy cập an toàn mà không cần phải sử dụng các giải pháp tạm thời rủi ro.

Xem NLA như một biện pháp kiểm soát an ninh cơ bản thay vì một tính năng tùy chọn. Giữ cho nó được kích hoạt, xác thực và giám sát như một phần của tư thế truy cập từ xa tổng thể của bạn. Khi bạn cần tắt nó, hãy giới hạn phạm vi ảnh hưởng, khắc phục vấn đề cơ bản và bật lại NLA càng sớm càng tốt.