Identity Policy & Authentication Rule trên FortiGate

1. Liên hệ thực tế

Khách hàng của anh Nam muốn phân quyền truy cập Internet theo phòng ban: phòng Kinh doanh được truy cập tự do, phòng Kỹ thuật chỉ được các dịch vụ nội bộ, và khách vãng lai (guest WiFi) phải đăng nhập bằng tài khoản được cấp trước khi vào mạng. Tất cả các nhóm này lại dùng chung một dải VLAN, không có subnet riêng để phân biệt bằng địa chỉ IP như trước.

Anh Nam bí: "Nếu không phân biệt được bằng IP, làm sao viết Policy khác nhau cho từng nhóm người dùng?"

Chị Lan: "Đây chính là lúc cần Identity-based Policy — Firewall Policy không còn dựa vào địa chỉ IP nguồn nữa, mà dựa vào danh tính người dùng đã xác thực. FortiGate sẽ yêu cầu người dùng đăng nhập trước, sau đó áp đúng Policy theo group mà tài khoản đó thuộc về."

Bài này giới thiệu khái niệm Identity Policy (Firewall Policy gắn với user/group) và cơ chế Authentication Rule đứng sau nó — nền tảng để kiểm soát truy cập theo con người thay vì chỉ theo địa chỉ IP.

2. Kiến thức cốt lõi

2.1 Identity-based Policy là gì

Identity-based Policy (IBP) là Firewall Policy có khai báo user hoặc user group trong trường nguồn (srcaddr/nhóm identity), thay vì chỉ dùng Address Object thuần địa chỉ IP. Khi traffic khớp một Policy như vậy, FortiGate không chỉ kiểm tra IP/port thông thường mà còn đòi hỏi phiên đó phải gắn với đúng danh tính người dùng đã khai báo.

config user group
    edit "Kinh-doanh"
        set member "nguyenvana" "tranthib"
    next
end

config firewall policy
    edit 70
        set name "kinh-doanh-full-access"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set groups "Kinh-doanh"
        set nat enable
    next
end

Tham số groups (kết hợp với srcaddr) là điểm khác biệt cốt lõi so với Policy IP-based thông thường ở các bài trước — Policy này chỉ áp dụng cho traffic đã được xác thực và thuộc đúng group Kinh-doanh.

2.2 Cơ chế FortiGate yêu cầu xác thực

Khi traffic đi qua FortiGate, Firewall Policy được kiểm tra theo các điều kiện match như source/destination address, service, interface và các tiêu chí khác. Nếu Policy có yêu cầu user/group identity, traffic phải có thông tin định danh phù hợp mới được Policy đó áp dụng — traffic chưa có identity không thể đáp ứng điều kiện user/group của một Identity-based Policy, vì vậy Policy đó không thể được áp dụng cho đến khi FortiGate xác định được identity phù hợp.

Đối với Captive Portal, nếu client chưa được xác thực nhưng traffic cần được xử lý bởi một Policy yêu cầu identity, FortiGate có thể chuyển client tới cơ chế xác thực để lấy thông tin user. Sau khi xác thực thành công, FortiGate sử dụng identity đó để xác định Policy phù hợp với user/group.

⚠️ Lưu ý: Cơ chế xác thực phụ thuộc phương thức FortiGate đang sử dụng. Với Captive Portal, người dùng thực hiện xác thực trực tiếp qua portal và FortiGate duy trì trạng thái xác thực đó cho các request tiếp theo. Với FSSO (Fortinet Single Sign-On), FortiGate nhận thông tin mapping giữa user và IP từ hệ thống FSSO (thường qua Domain Controller) thay vì yêu cầu người dùng đăng nhập qua captive portal — người dùng không nhìn thấy bất kỳ bước xác thực nào diễn ra.

2.3 Captive Portal — hình thức xác thực trực tiếp qua trình duyệt

Captive Portal buộc người dùng phải nhập thông tin đăng nhập qua một trang web trước khi được cấp quyền truy cập — phổ biến cho WiFi khách, đúng nhu cầu tình huống mở đầu bài.

config user group
    edit "Guest-WiFi"
        set member "guest01" "guest02"
    next
end

config system interface
    edit "wifi-guest"
        set security-mode captive-portal
        set security-groups "Guest-WiFi"
    next
end

config user security-exempt-list
    edit "exempt-dns"
        config rule
            edit 1
                set dstaddr "all"
                set service "DNS"
            next
        end
    next
end

Captive Portal cấu hình trực tiếp trên interface (security-mode captive-portal), không phải trên Firewall Policy — mọi client trên interface đó đều phải xác thực trừ traffic khớp security-exempt-list (thường whitelist DNS để trình duyệt phân giải được trang đăng nhập).

⚠️ Lưu ý: Cần khai báo security-exempt-list cho ít nhất DNS (và có thể cả traffic tới server xác thực bên ngoài nếu dùng FortiAuthenticator/RADIUS) — nếu không, client sẽ không phân giải được tên miền của chính trang captive portal, dẫn tới không đăng nhập được.

2.4 Authentication Rule — quy tắc chọn phương thức xác thực

Authentication Rule (config authentication rule) quyết định phương thức xác thực nào sẽ được áp dụng khi FortiGate cần xác thực traffic — kết hợp điều kiện nguồn/đích với scheme xác thực cụ thể (form-based, NTLM, FSSO...), trước khi Identity Policy có thể được đánh giá.

config authentication scheme
    edit "scheme-form"
        set method form
        set user-database "local"
    next
end

config authentication rule
    edit "rule-guest"
        set srcintf "wifi-guest"
        set srcaddr "all"
        set ip-based enable
        set active-auth-method "scheme-form"
    next
end

Authentication Rule cho phép kết hợp nhiều scheme khác nhau tùy vào nguồn/đích traffic — ví dụ nội bộ dùng FSSO (xác thực ngầm qua Domain Controller, người dùng không thấy trang login), còn WiFi khách dùng form-based captive portal.

2.5 Bảng tổng hợp các thành phần liên quan

⚠️ Lưu ý: Identity Policy chỉ hoạt động đúng khi đã có nguồn xác thực phía sau (local user database, LDAP/AD, RADIUS, hoặc FSSO) — các phương thức tích hợp cụ thể với LDAP, RADIUS, SAML sẽ được trình bày chi tiết ở nhóm bài Authentication & User Management phía sau khóa học.

3. Hỏi & Đáp

Nếu một client đã xác thực nhưng không thuộc group nào trong bất kỳ Policy nào, điều gì xảy ra?

Traffic của client đó sẽ không khớp được Policy identity-based nào, và tiếp tục duyệt xuống các Policy khác (kể cả Policy IP-based thông thường) theo đúng thứ tự Policy Lookup — nếu không có Policy nào khớp, cuối cùng rơi vào Implicit Deny.

Captive Portal và Local-In Policy có liên quan gì tới nhau không?

Không liên quan trực tiếp — Local-In Policy kiểm soát traffic đến chính FortiGate (quản trị), còn Captive Portal kiểm soát traffic đi qua FortiGate của client trên một interface cụ thể, yêu cầu xác thực trước khi được coi là "đã đủ điều kiện" để tiếp tục qua Firewall Policy.

Có thể áp Identity Policy cho traffic HTTPS không cần Captive Portal không?

Có — với các phương thức xác thực ngầm như FSSO (Fortinet Single Sign-On), người dùng không cần nhìn thấy trang đăng nhập nào; FortiGate nhận diện danh tính người dùng gián tiếp qua thông tin đăng nhập Windows Domain đã có sẵn, phù hợp cho môi trường doanh nghiệp có Active Directory.

Nếu đổi thứ tự đặt Identity Policy sau Policy IP-based thông thường (allow all), có vấn đề gì không?

Có — giống nguyên tắc Policy Lookup đã học, nếu Policy "allow all" (không yêu cầu identity) đặt trước, traffic sẽ khớp ngay Policy đó và không bao giờ tới lượt Identity Policy phía sau được xét, khiến cơ chế phân quyền theo user/group mất tác dụng.

4. Quiz

Câu 1: Identity-based Policy khác Firewall Policy IP-based thông thường ở điểm nào?

• A. Không hỗ trợ NAT
• B. Yêu cầu traffic phải gắn với đúng user/group đã xác thực, qua tham số groups
• C. Chỉ áp dụng cho IPv6
• D. Không thể kết hợp với UTM profile

Câu 2: Khi client chưa xác thực gửi traffic và không có Policy nào phù hợp không yêu cầu identity, FortiGate sẽ làm gì?

• A. Tự động chặn vĩnh viễn địa chỉ IP đó
• B. Chủ động yêu cầu xác thực trước khi cho tiếp tục
• C. Bỏ qua toàn bộ Policy và cho phép truy cập
• D. Khởi động lại dịch vụ web

Câu 3: Captive Portal được cấu hình ở đâu trên FortiGate?

• A. Trực tiếp trên Firewall Policy
• B. Trên interface, qua tham số security-mode captive-portal
• C. Chỉ cấu hình được qua FortiAnalyzer
• D. Trên DNS Server

Câu 4: security-exempt-list trong cấu hình Captive Portal dùng để làm gì?

• A. Danh sách user được miễn phí sử dụng dịch vụ
• B. Cho phép một số traffic (như DNS) đi qua mà không cần xác thực, để trang đăng nhập hoạt động được
• C. Chặn toàn bộ traffic không phân biệt
• D. Không có tác dụng gì với captive portal

Câu 5: Authentication Rule có vai trò gì trong luồng xác thực?

• A. Thay thế hoàn toàn Firewall Policy
• B. Quyết định phương thức xác thực (scheme) nào áp dụng cho nguồn/đích traffic cụ thể
• C. Chỉ dùng để đổi mật khẩu admin
• D. Không liên quan tới Identity Policy

👉 Đáp án

Câu 1: B Identity-based Policy yêu cầu traffic phải gắn với đúng user hoặc user group đã xác thực (qua tham số groups), khác với Policy IP-based chỉ dựa vào địa chỉ IP nguồn thông thường.

Câu 2: B Khi không tìm được Policy phù hợp mà không yêu cầu identity, FortiGate chủ động yêu cầu xác thực (qua captive portal, NTLM, hoặc phương thức đã cấu hình) trước khi xử lý tiếp traffic đó.

Câu 3: B Captive Portal được cấu hình trên interface thông qua tham số security-mode captive-portal, không phải trực tiếp trên Firewall Policy.

Câu 4: B security-exempt-list cho phép một số traffic nhất định (thường là DNS) đi qua mà không cần xác thực trước, đảm bảo trình duyệt phân giải được tên miền của trang đăng nhập captive portal.

Câu 5: B Authentication Rule quyết định phương thức xác thực (scheme) cụ thể nào — form-based, NTLM, FSSO... — sẽ được áp dụng dựa trên điều kiện nguồn/đích của traffic.

📚 Bài viết thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng