Single Sign-On (FSSO) trên FortiGate — Xác thực trong suốt qua Active Directory

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

Sau khi triển khai LDAP, nhân viên đã dùng chung tài khoản AD để xác thực khi FortiGate yêu cầu — nhưng chị Lan nhận được phản ánh: "Sao mỗi lần mở trình duyệt lại phải đăng nhập lại? Em vừa gõ password vào máy tính lúc sáng rồi mà."

Đây chính là hạn chế của Identity-based Policy dùng LDAP/RADIUS thông thường: FortiGate vẫn cần user tự nhập username/password mỗi khi có traffic khớp Policy yêu cầu xác thực (qua pop-up trình duyệt hoặc Captive Portal). Với những công ty muốn trải nghiệm "đăng nhập một lần" thực sự — đăng nhập vào máy tính (domain) là đủ, không cần gõ lại gì nữa khi duyệt web — cần đến FSSO (Fortinet Single Sign-On).

Anh Nam hỏi: "Vậy khác gì SAML mình học ở bài trước?" Chị Lan giải thích: "SAML là cho các dịch vụ hỗ trợ redirect trình duyệt như SSL-VPN. FSSO thì âm thầm hơn — nó theo dõi sự kiện đăng nhập Windows AD ở tầng hạ tầng, rồi tự động 'biết' user nào đang dùng IP nào, áp Policy luôn mà user không hề hay biết có bước xác thực nào diễn ra."

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

2.1 FSSO là gì và giải quyết vấn đề gì

FSSO (Fortinet Single Sign-On) là cơ chế cho phép FortiGate nhận diện danh tính người dùng mà không cần yêu cầu họ đăng nhập lại trên firewall — bằng cách theo dõi các sự kiện đăng nhập đã xảy ra ở nơi khác (thường là Windows Active Directory) và ánh xạ chúng sang địa chỉ IP nguồn.

So sánh nhanh với các phương thức đã học trong Nhóm 6:

2.2 Các loại Agent trong FSSO

FSSO cần một agent thu thập sự kiện đăng nhập từ AD, gồm các mô hình chính:

• Collector Agent (Agent-based, DC Agent mode) — cài trên một máy chủ Windows riêng, kết hợp với DC Agent cài trên từng Domain Controller để nhận thông báo logon event theo thời gian thực. Đây là mô hình ổn định và phổ biến nhất trong triển khai doanh nghiệp.
• Agentless Polling mode — Collector Agent (hoặc chính FortiGate ở một số cấu hình) chủ động polling Windows Security Event Log trên Domain Controller theo chu kỳ, không cần cài thêm DC Agent trên từng DC. Đơn giản triển khai hơn nhưng độ trễ nhận diện phụ thuộc vào chu kỳ polling.
• RADIUS Accounting (RSSO) — nhận diện qua bản tin RADIUS Accounting do RADIUS server forward, phù hợp khi user đã xác thực qua RADIUS ở một hệ thống khác (VD: NAC, VPN concentrator khác) và muốn FortiGate tận dụng lại thông tin đó.

🔄 Khác biệt version FortiOS: Cấu hình FSSO cơ bản (config user fsso) ổn định qua các bản 7.0/7.2/7.4. Từ 7.4 trở lên, một số cải tiến về việc dùng RADIUS Accounting để cập nhật IP cho SSL-VPN user (tránh trường hợp user đổi IP khi VPN nhưng FSSO chưa cập nhật kịp) được bổ sung — nếu môi trường có SSL-VPN kết hợp FSSO, cần kiểm tra kỹ theo từng bản vá cụ thể.

2.3 Cấu hình FSSO Agent trên FortiGate — tổng quan luồng

config user fsso
    edit "FSSO-COMPANY"
        set server "10.10.10.30"
        set password ********
        set port 8000
    next
end

• server — địa chỉ máy chủ đang chạy FSSO Collector Agent (không phải Domain Controller trực tiếp).
• password — mật khẩu xác thực giữa FortiGate và Collector Agent, đặt khi cài đặt Collector Agent trên Windows.
• port — mặc định 8000, cổng Collector Agent lắng nghe kết nối từ FortiGate.

Sau khi FSSO server sẵn sàng, group ánh xạ tương tự các phương thức khác:

config user group
    edit "GRP_FSSO_NHANVIEN"
        set group-type fsso-service
        set member "CN=NhanVien,OU=Groups,DC=company,DC=local"
    next
end

Khác với firewall group-type dùng config match, group-type fsso-service tham chiếu trực tiếp DN của AD Group đã được Collector Agent đồng bộ về FortiGate — danh sách group khả dụng thường được lấy tự động khi FortiGate kết nối thành công tới Collector Agent (nút "Apply & Refresh" trên GUI).

2.4 Khi nào chọn FSSO thay vì Identity-based Policy thông thường

FSSO phù hợp nhất khi:

• Toàn bộ máy trạm trong công ty đã join Active Directory domain.
• Muốn áp Policy theo phòng ban/group AD một cách "trong suốt" — nhân viên không cảm nhận được có bước xác thực nào ở tầng firewall.
• Cần phân biệt traffic theo user thay vì chỉ theo IP tĩnh, nhưng không muốn ảnh hưởng tới trải nghiệm người dùng bằng pop-up đăng nhập.

Ngược lại, với máy không join domain (laptop cá nhân, thiết bị BYOD), FSSO sẽ không nhận diện được — trường hợp này vẫn cần quay lại Identity-based Policy (Local user/LDAP/RADIUS đã học) hoặc Captive Portal.

⚠️ Lưu ý: FSSO không phải là cơ chế xác thực độc lập — nó tin tưởng vào sự kiện logon đã xảy ra ở AD. Nếu một máy tính dùng chung nhiều người (không đăng xuất giữa các phiên) hoặc NAT nhiều user qua cùng một IP nguồn trước khi tới FortiGate, việc ánh xạ user-IP có thể sai lệch — đây là giới hạn cần lưu ý khi tư vấn triển khai cho khách hàng có mô hình mạng phức tạp.

3. Hỏi & Đáp

FSSO có thay thế được LDAP không?

Không hoàn toàn. FSSO thường vẫn cần một LDAP server đứng sau để FortiGate lấy thêm thông tin cấu trúc group (khi cấu hình User Group Source là Local thay vì Collector Agent). Hai cơ chế này thường phối hợp với nhau: LDAP cung cấp cấu trúc group, FSSO cung cấp khả năng nhận diện "trong suốt" không cần đăng nhập lại.

Vì sao user vẫn bị yêu cầu đăng nhập dù đã bật FSSO?

Thường do Collector Agent chưa nhận được sự kiện logon của user đó (VD: máy tính chưa đăng xuất/đăng nhập lại sau khi bật FSSO, hoặc DC Agent chưa cài đúng trên Domain Controller mà user đó xác thực), hoặc IP nguồn của user không khớp với bảng ánh xạ user-IP mà Collector Agent đang giữ (thường gặp khi có NAT hoặc DHCP đổi IP giữa chừng).

FSSO có hoạt động được với máy không join domain không?

Không. FSSO dựa hoàn toàn vào sự kiện đăng nhập domain Windows AD — máy không join domain (hoặc user đăng nhập bằng local account của máy) sẽ không sinh ra sự kiện logon mà Collector Agent có thể nhận diện.

Có cần cài phần mềm gì trên máy trạm người dùng không?

Với mô hình Collector Agent + DC Agent chuẩn, không cần cài gì thêm trên máy trạm — DC Agent chỉ cài trên Domain Controller. Một số mô hình mở rộng khác (như FortiClient SSO Mobility Agent) có cài thêm agent trên máy trạm để tăng độ chính xác, nhưng đây là lựa chọn bổ sung, không bắt buộc với FSSO cơ bản.

4. Quiz

Câu 1: Điểm khác biệt cốt lõi của FSSO so với Identity-based Policy dùng LDAP/RADIUS là gì?

• A. FSSO nhanh hơn về tốc độ mạng
• B. FSSO không yêu cầu user đăng nhập lại trên FortiGate, tận dụng sự kiện logon đã có từ AD
• C. FSSO chỉ dùng được với RADIUS
• D. FSSO không cần Active Directory

Câu 2: Thành phần nào cài trên Domain Controller để gửi sự kiện logon về Collector Agent?

• A. FortiClient
• B. DC Agent
• C. FortiToken Mobile
• D. RADIUS Client

Câu 3: Group-type nào dùng cho FSSO trong config user group?

• A. firewall
• B. guest
• C. fsso-service
• D. rsso

Câu 4: FSSO gặp hạn chế rõ nhất trong trường hợp nào?

• A. Máy trạm đã join domain, đăng nhập bằng tài khoản AD
• B. Nhiều user dùng chung một máy hoặc NAT chung một IP trước khi tới FortiGate
• C. Công ty chỉ có một Domain Controller
• D. FortiGate đặt ở chế độ NAT mode

👉 Đáp án

Câu 1: B FSSO tận dụng lại sự kiện đăng nhập đã xảy ra ở AD, giúp FortiGate nhận diện user mà không cần yêu cầu xác thực thêm lần nữa ở tầng firewall.

Câu 2: B DC Agent cài trực tiếp trên từng Domain Controller, có nhiệm vụ theo dõi sự kiện logon và gửi thông tin về Collector Agent.

Câu 3: C fsso-service là group-type chuyên dùng cho FSSO, tham chiếu trực tiếp AD Group đã đồng bộ qua Collector Agent.

Câu 4: B Khi nhiều user cùng dùng chung một địa chỉ IP (máy chung, NAT gộp), việc ánh xạ user-IP của FSSO dễ bị sai lệch, dẫn tới áp nhầm Policy cho user khác.

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

🧭 Điều hướng