Hiểu đúng về NPS Policy: Vì sao người dùng bị từ chối đăng nhập dù mật khẩu hoàn toàn chính xác?
Một trong những tình huống khiến quản trị viên Windows Server đau đầu nhất là:
Nguyên nhân rất nhiều trường hợp không nằm ở mật khẩu, mà nằm trong NPS Policy Processing Engine.
Nắm được cách NPS xử lý Policy sẽ giúp bạn rút ngắn đáng kể thời gian troubleshooting.
Hai loại Policy quan trọng nhất trong NPS
NPS sử dụng hai loại policy với vai trò hoàn toàn khác nhau.
Connection Request Policy
Đây là chính sách quyết định yêu cầu xác thực sẽ được xử lý ở đâu.
Ví dụ:
Có thể hình dung Connection Request Policy giống như lễ tân của một tòa nhà. Nhiệm vụ của lễ tân không phải xác minh khách có được vào hay không, mà chỉ quyết định sẽ đưa khách đến đúng phòng hoặc đúng bộ phận xử lý.
Network Policy
Sau khi biết yêu cầu sẽ được xử lý ở đâu, NPS mới sử dụng Network Policy để trả lời câu hỏi quan trọng hơn:
Người dùng này có được phép truy cập hay không?
Network Policy có thể kiểm tra rất nhiều điều kiện như:
Nói ngắn gọn:
Nếu mỗi VPN Server hoặc Wireless Controller đều lưu chính sách xác thực riêng, việc quản trị sẽ nhanh chóng trở nên phức tạp khi hệ thống mở rộng.
RADIUS giải quyết vấn đề này bằng cách tập trung toàn bộ chính sách xác thực tại Network Policy Server (NPS). Thay vì cấu hình trên từng thiết bị, quản trị viên chỉ cần tạo và cập nhật policy một lần trên NPS, mọi NAS (VPN Server, Switch, Wireless Controller...) sẽ sử dụng chung chính sách đó. Điều này giúp quản lý nhất quán và giảm đáng kể công sức vận hành. Lợi ích của RADIUS Server Group
Trong các hệ thống lớn, một máy chủ RADIUS có thể trở thành điểm nghẽn hoặc điểm lỗi duy nhất (Single Point of Failure).
RADIUS Server Group cho phép nhiều máy chủ RADIUS cùng tham gia xử lý yêu cầu xác thực. NPS có thể phân phối các yêu cầu đến nhiều máy chủ để cân bằng tải và tự động chuyển sang máy chủ khác nếu một máy gặp sự cố. Nhờ đó, hệ thống có khả năng mở rộng tốt hơn và luôn sẵn sàng phục vụ.
Vì sao nên đặt RADIUS Proxy ngoài Firewall?
Một kiến trúc phổ biến là đặt RADIUS Proxy trong vùng DMZ, còn máy chủ NPS chứa Active Directory và chính sách xác thực nằm ở mạng nội bộ.
Thiết kế này mang lại nhiều lợi ích:
Firewall khi đó chỉ cần mở đúng các cổng RADIUS cần thiết giữa Proxy và NPS nội bộ:
Hoặc trong một số hệ thống cũ:
Việc chỉ mở đúng các cổng cần thiết giúp thực hiện nguyên tắc Least Privilege trong thiết kế mạng, giảm nguy cơ khai thác các dịch vụ không cần thiết.
Một lưu ý quan trọng khi triển khai NPS
Khi vừa cài đặt role Network Policy Server, NPS đã có sẵn hai Network Policy mặc định.
Hai policy này từ chối toàn bộ các yêu cầu Remote Access. Điều đó có nghĩa là nếu chưa tạo hoặc chỉnh sửa Network Policy phù hợp, mọi kết nối VPN hoặc 802.1X đều sẽ bị từ chối, dù người dùng nhập đúng thông tin đăng nhập.
Đây là nguyên nhân rất phổ biến khiến quản trị viên mới triển khai NPS nhầm tưởng hệ thống xác thực đang gặp lỗi.
Trong bài thực hành tiếp theo, chúng ta sẽ cùng cấu hình Connection Request Policy và Network Policy trên NPS để thấy rõ cách các chính sách này phối hợp với nhau trong quá trình xác thực và cấp quyền truy cập.
Một trong những tình huống khiến quản trị viên Windows Server đau đầu nhất là:
Người dùng nhập đúng Username, đúng Password, nhưng VPN hoặc Wi-Fi 802.1X vẫn báo Access Denied.
Nguyên nhân rất nhiều trường hợp không nằm ở mật khẩu, mà nằm trong NPS Policy Processing Engine.
Nắm được cách NPS xử lý Policy sẽ giúp bạn rút ngắn đáng kể thời gian troubleshooting.
Hai loại Policy quan trọng nhất trong NPS
NPS sử dụng hai loại policy với vai trò hoàn toàn khác nhau.
Connection Request Policy
Đây là chính sách quyết định yêu cầu xác thực sẽ được xử lý ở đâu.
Ví dụ:
- Xác thực ngay trên máy chủ NPS bằng Active Directory.
- Chuyển tiếp sang một RADIUS Server khác.
- Chuyển đến RADIUS Server Group để cân bằng tải hoặc dự phòng.
Có thể hình dung Connection Request Policy giống như lễ tân của một tòa nhà. Nhiệm vụ của lễ tân không phải xác minh khách có được vào hay không, mà chỉ quyết định sẽ đưa khách đến đúng phòng hoặc đúng bộ phận xử lý.
Network Policy
Sau khi biết yêu cầu sẽ được xử lý ở đâu, NPS mới sử dụng Network Policy để trả lời câu hỏi quan trọng hơn:
Người dùng này có được phép truy cập hay không?
Network Policy có thể kiểm tra rất nhiều điều kiện như:
- Người dùng thuộc nhóm AD nào.
- Đăng nhập bằng phương thức EAP nào.
- Đăng nhập trong khung giờ nào.
- Kết nối từ VPN, Wi-Fi hay Switch 802.1X.
- Gán VLAN động hoặc áp dụng các thuộc tính RADIUS sau khi xác thực thành công.
Nói ngắn gọn:
- Connection Request Policy quyết định nơi xử lý yêu cầu.
- Network Policy quyết định có cấp quyền truy cập hay không.
Nếu mỗi VPN Server hoặc Wireless Controller đều lưu chính sách xác thực riêng, việc quản trị sẽ nhanh chóng trở nên phức tạp khi hệ thống mở rộng.
RADIUS giải quyết vấn đề này bằng cách tập trung toàn bộ chính sách xác thực tại Network Policy Server (NPS). Thay vì cấu hình trên từng thiết bị, quản trị viên chỉ cần tạo và cập nhật policy một lần trên NPS, mọi NAS (VPN Server, Switch, Wireless Controller...) sẽ sử dụng chung chính sách đó. Điều này giúp quản lý nhất quán và giảm đáng kể công sức vận hành. Lợi ích của RADIUS Server Group
Trong các hệ thống lớn, một máy chủ RADIUS có thể trở thành điểm nghẽn hoặc điểm lỗi duy nhất (Single Point of Failure).
RADIUS Server Group cho phép nhiều máy chủ RADIUS cùng tham gia xử lý yêu cầu xác thực. NPS có thể phân phối các yêu cầu đến nhiều máy chủ để cân bằng tải và tự động chuyển sang máy chủ khác nếu một máy gặp sự cố. Nhờ đó, hệ thống có khả năng mở rộng tốt hơn và luôn sẵn sàng phục vụ.
Vì sao nên đặt RADIUS Proxy ngoài Firewall?
Một kiến trúc phổ biến là đặt RADIUS Proxy trong vùng DMZ, còn máy chủ NPS chứa Active Directory và chính sách xác thực nằm ở mạng nội bộ.
Thiết kế này mang lại nhiều lợi ích:
- Không để máy chủ xác thực nội bộ tiếp xúc trực tiếp với Internet.
- Giảm bề mặt tấn công đối với Active Directory.
- Chỉ chuyển tiếp các gói RADIUS hợp lệ vào mạng nội bộ.
- Dễ kiểm soát và ghi log toàn bộ lưu lượng xác thực.
Firewall khi đó chỉ cần mở đúng các cổng RADIUS cần thiết giữa Proxy và NPS nội bộ:
- UDP 1812 (Authentication)
- UDP 1813 (Accounting)
Hoặc trong một số hệ thống cũ:
- UDP 1645
- UDP 1646
Việc chỉ mở đúng các cổng cần thiết giúp thực hiện nguyên tắc Least Privilege trong thiết kế mạng, giảm nguy cơ khai thác các dịch vụ không cần thiết.
Một lưu ý quan trọng khi triển khai NPS
Khi vừa cài đặt role Network Policy Server, NPS đã có sẵn hai Network Policy mặc định.
Hai policy này từ chối toàn bộ các yêu cầu Remote Access. Điều đó có nghĩa là nếu chưa tạo hoặc chỉnh sửa Network Policy phù hợp, mọi kết nối VPN hoặc 802.1X đều sẽ bị từ chối, dù người dùng nhập đúng thông tin đăng nhập.
Đây là nguyên nhân rất phổ biến khiến quản trị viên mới triển khai NPS nhầm tưởng hệ thống xác thực đang gặp lỗi.
Trong bài thực hành tiếp theo, chúng ta sẽ cùng cấu hình Connection Request Policy và Network Policy trên NPS để thấy rõ cách các chính sách này phối hợp với nhau trong quá trình xác thực và cấp quyền truy cập.