Tại sao tôi phải dùng lệnh sss_cache -E sau khi thay đổi cấu hình SSSD?

SSSD lưu trữ (cache) thông tin người dùng và nhóm để tăng tốc độ. Khi bạn thay đổi quyền trong sssd.conf (ví dụ: thêm nhóm vào simple_allow_groups), SSSD vẫn đọc từ cache cũ. Lệnh 'sss_cache -E' buộc SSSD xóa toàn bộ cache và tải lại thông tin mới nhất từ Active Directory, đảm bảo các quy tắc truy cập mới được áp dụng ngay lập tức.

Cấu hình SSSD nâng cao: Hướng dẫn cấp Sudo và giới hạn đăng nhập AD • ZingServer

Nếu bạn đang đọc bài này, rất có thể bạn vừa thực hiện thành công 7 bước join VPS Linux vào AD bằng realmd. VPS của bạn đã “nhìn thấy” Active Directory.

Nhưng công việc chưa dừng lại ở đó. Cấu hình realmd mặc định có một vấn đề bảo mật lớn: nó cho phép bất kỳ ai trong ActiveDirectory cũng có thể đăng nhập SSH vào VPS của bạn. Thêm vào đó, việc phân quyền sudo cũng cần được kiểm soát chặt chẽ hơn.

Bài viết này là phần 2, tập trung vào cấu hình SSSD nâng cao để siết chặt an ninh. Chúng ta sẽ giải quyết 2 mục tiêu chính:

Giới hạn đăng nhập (Access Control): Chỉ cho phép các nhóm AD cụ thể (ví dụ: Linux_Admins) được phép đăng nhập.
Phân quyền Sudo nâng cao: Cấp quyền quản trị sudo cho user AD một cách linh hoạt và an toàn.

Nếu bạn còn phân vân tại sao nên dùng SSSD, hãy đọc bài so sánh chi tiết SSSD vs Winbind của chúng tôi. Và nếu bạn đang dùng Winbind, đây là hướng dẫn di chuyển sang SSSD an toàn.

Tóm tắt nhanh: Để siết chặt bảo mật SSSD, bạn cần chỉnh sửa file /etc/sssd/sssd.conf.

Giới hạn đăng nhập: Dùng access_provider = simple và simple_allow_groups = [email protected].

Cấp Sudo: Tạo file trong /etc/sudoers.d/ (ví dụ: visudo -f /etc/sudoers.d/ad_admins) và thêm dòng %[email protected] ALL=(ALL) ALL.

Áp dụng: Luôn chạy sudo systemctl restart sssd và sudo sss_cache -E sau khi thay đổi.

Nội dung chính

Điều kiện tiên quyết (Quan trọng)

Bài viết này giả định bạn đã hoàn thành các bước sau (từ bài hướng dẫn realmd):

VPS chạy RHEL, CentOS 7/8/9, AlmaLinux, hoặc Rocky Linux.
VPS đã join domain AD thành công bằng lệnh realm join.
DNS và NTP đã được cấu hình chính xác trỏ về Domain Controller (DC).
Bạn có quyền root hoặc sudo trên VPS.

Trước khi bắt đầu, hãy đảm bảo bạn đã cài đặt đủ các gói hỗ trợ. Bài “realmd” đã cài hầu hết, nhưng để cấu hình nâng cao, chúng ta cần:

sssd-ad, sssd-tools, adcli: Các gói SSSD cốt lõi (đã cài).
oddjob-mkhomedir: Rất quan trọng, dùng để tự động tạo thư mục home cho user AD khi họ đăng nhập lần đầu (đã cài ở bài realmd).
libsss-sudo: Gói này cần cài thêm nếu bạn muốn sử dụng phương pháp cấp Sudo tập trung.

# Cài đặt gói hỗ trợ Sudo tập trung (nếu cần)
sudo dnf install libsss-sudo

Cấu hình SSSD: Giới hạn đăng nhập AD (Access Control)

Đây là bước quan trọng nhất để bảo mật VPS của bạn. Mặc định, SSSD cho phép mọi tài khoản AD đã xác thực được đăng nhập. Chúng ta phải thay đổi điều này ngay lập tức.

Tất cả cấu hình sẽ được thực hiện trong file /etc/sssd/sssd.conf.

Cách 1: Dùng `simple_allow_groups` (Đơn giản & khuyến nghị)

Đây là cách dễ hiểu và phổ biến nhất. Chúng ta ra lệnh cho SSSD chuyển sang chế độ “đơn giản” và chỉ định một danh sách (whitelist) các nhóm được phép.

Mở file cấu hình SSSD:
```
sudo nano /etc/sssd/sssd.conf
```
Tìm đến mục [domain/ad.example.com] của bạn.

Thêm 2 dòng sau vào cuối mục domain đó:

[domain/ad.example.com]
...
# ================================
# ACCESS CONTROL - SIMPLE MODE
# ================================
access_provider = simple
simple_allow_groups = [email protected], [email protected]

Giải thích:

access_provider = simple: Chuyển SSSD từ chế độ ad (cho phép tất cả) sang simple (chỉ cho phép danh sách).
simple_allow_groups: Danh sách các nhóm được phép đăng nhập. Bạn phải ghi rõ tên nhóm và domain. Nếu tên nhóm có khoảng trắng, hãy dùng dấu gạch chéo ngược (ví dụ: Domain\ [email protected]).

Cách 2: Dùng `ad_access_filter` (Nâng cao & linh hoạt)

Cách này phức tạp hơn nhưng mạnh mẽ hơn. Bạn giữ nguyên access_provider = ad nhưng thêm vào một bộ lọc (filter) theo cú pháp truy vấn LDAP.

Cách này hữu ích nếu bạn có các quy tắc phức tạp, ví dụ: “Cho phép nhóm A, VÀ user đó phải thuộc nhóm B”.

Mở file /etc/sssd/sssd.conf.
Trong mục [domain/...], hãy đảm bảo access_provider = ad (hoặc xóa dòng đó đi để dùng mặc định).

Thêm dòng ad_access_filter:

[domain/ad.example.com]
...
# ==================================
# ACCESS CONTROL - AD FILTER MODE
# ==================================
access_provider = ad
ad_access_filter = (memberOf=cn=Linux_Admins,ou=Groups,dc=ad,dc=example,dc=com)

Giải thích:

ad_access_filter: SSSD sẽ chỉ cho phép đăng nhập nếu đối tượng user thỏa mãn bộ lọc LDAP này.
Cú pháp trên yêu cầu bạn phải biết đường dẫn Distinguished Name (DN) đầy đủ đến nhóm của mình trong AD.

Khuyến nghị: Đối với hầu hết các VPS, Cách 1 (simple_allow_groups) là đủ an toàn, dễ đọc và dễ bảo trì hơn.

Cách 3: Dùng lệnh `realm permit` (Cách của “realmd”)

Công cụ realmd cũng cung cấp các lệnh để quản lý truy cập. Đây là cách làm nhanh, không cần sửa file .conf.

Khi bạn chạy realm join, mặc định là không ai bị cấm. Bạn cần thay đổi điều đó:

Cấm tất cả mọi người trước:
```
sudo realm deny --all
```

Cho phép (permit) từng nhóm cụ thể mà bạn muốn:

sudo realm permit -g '[email protected]'
sudo realm permit -g '[email protected]'

Kiểm tra lại danh sách:
```
sudo realm list
```

Lệnh realm permit sẽ tự động chỉnh sửa file sssd.conf hoặc quản lý quyền truy cập theo cách riêng của nó, nhưng kết quả cuối cùng là như nhau: chỉ các nhóm được “permit” mới có thể đăng nhập.

Cấu hình cấp quyền Sudo cho nhóm AD

Sau khi user AD có thể đăng nhập, họ chỉ là user thường. Họ cần quyền sudo để quản trị hệ thống. Bài hướng dẫn realmd có đề cập đến realm permit để cấp sudo, nhưng cách đó khá cơ bản.

Dưới đây là 2 cách “nâng cao” và linh hoạt hơn.

Cách 1: Cấu hình Local (Phổ biến & linh hoạt nhất)

Đây là cách an toàn và được khuyến nghị nhất. Chúng ta sẽ tạo một file cấu hình riêng trong thư mục /etc/sudoers.d/ để cấp quyền cho nhóm AD.

Luôn dùng lệnh visudo để chỉnh sửa. Lệnh này sẽ kiểm tra cú pháp trước khi lưu, tránh làm bạn bị khóa khỏi sudo.
```
# Tạo một file mới tên là 'ad_admins'
sudo visudo -f /etc/sudoers.d/ad_admins
```

Thêm nội dung sau vào file.
Ví dụ 1: Cấp full quyền Sudo Cho phép nhóm [email protected] chạy mọi lệnh.

# Cấp full quyền sudo cho nhóm Linux Admins từ AD
# Lưu ý dấu % ở đầu để chỉ định đây là một nhóm
%[email protected] ALL=(ALL) ALL

Ví dụ 2: Cấp quyền Sudo nâng cao (dùng Cmnd_Alias) Chỉ cho phép nhóm DevOps_Team khởi động lại dịch vụ web. Đây là cách phân quyền tối thiểu (least privilege) rất an toàn.

# Định nghĩa một nhóm lệnh tên là APACHE_CMDS
Cmnd_Alias APACHE_CMDS = /bin/systemctl restart httpd, /bin/systemctl status httpd

# Chỉ cho phép nhóm DevOps chạy các lệnh trong APACHE_CMDS
%[email protected] ALL=(ALL) APACHE_CMDS

Lưu và thoát file. Quyền sudo sẽ có hiệu lực ngay lập tức (sau khi user đăng xuất và đăng nhập lại).

Cách 2: Cấu hình tập trung (Quản lý Sudo từ AD)

Đây là giải pháp chuyên nghiệp, dành cho các doanh nghiệp lớn. Thay vì định nghĩa sudo trên từng VPS, bạn định nghĩa các quy tắc sudo (gọi là sudoRole) bên trong Active Directory. SSSD trên VPS sẽ đọc và áp dụng các quy tắc này.

Điều kiện (Phía AD): Bạn phải mở rộng AD Schema (AD Schema Extension) để hỗ trợ các đối tượng sudoRole. Việc này nằm ngoài phạm vi bài viết này và cần được thực hiện bởi AD Admin.

Các bước (Phía VPS Linux):

Cài đặt gói libsss-sudo:
```
sudo dnf install libsss-sudo
```
Sửa /etc/sssd/sssd.conf: Bạn cần SSSD biết rằng nó phải tìm quy tắc sudo.
- Trong mục [sssd], thêm sudo vào services:
```
[sssd]
services = nss, pam, sudo
...
```
- Trong mục [domain/ad.example.com], thêm các dòng sau:
```
[domain/ad.example.com]
...
# ================================
# SUDO PROVIDER - CENTRALIZED
# ================================
sudo_provider = ad
ldap_sudo_search_base = ou=Sudoers,dc=ad,dc=example,dc=com

# Tinh chỉnh cache (tùy chọn)
ldap_sudo_smart_refresh_interval = 900
ldap_sudo_full_refresh_interval = 21600
```
- Giải thích:
  - sudo_provider = ad: Yêu cầu SSSD lấy quy tắc sudo từ AD.
  - ldap_sudo_search_base: Chỉ cho SSSD biết phải tìm các quy tắc sudoRole ở đâu trong cây AD (thay bằng OU của bạn).
  - ldap_sudo_smart_refresh_interval: Tần suất (giây) kiểm tra thay đổi nhỏ (mặc định 15 phút).
  - ldap_sudo_full_refresh_interval: Tần suất (giây) tải lại toàn bộ quy tắc (mặc định 6 giờ).
Ghi chú kỹ thuật (sudo_provider = ad vs ldap): Bạn có thể thấy một số tài liệu cũ hơn (như trên RHEL 6) sử dụng sudo_provider = ldap. Tuy nhiên, vì chúng ta đang dùng id_provider = ad (do realmd tự cấu hình), SSSD đã “hiểu” toàn bộ cấu trúc AD.

Việc đặt sudo_provider = ad là cách làm hiện đại và chính xác nhất. Nó cho phép SSSD tự động tìm kiếm các quy tắc Sudo bằng cách sử dụng Global Catalog của AD.
Sửa /etc/nsswitch.conf: Cuối cùng, bạn phải bảo hệ điều hành Linux “hãy hỏi SSSD” khi tra cứu quyền sudo.
- Mở file: sudo nano /etc/nsswitch.conf
- Tìm dòng sudoers: và thêm sss vào.
```
# Dòng cũ:
# sudoers: files

# Dòng mới:
sudoers: files sss
```

Sau khi hoàn tất 3 bước này và khởi động lại SSSD, VPS sẽ tự động nhận các quy tắc sudo mà bạn định nghĩa tập trung trên AD.

Tinh chỉnh SSSD: Tối ưu trải nghiệm và hiệu suất

Đây là các tinh chỉnh “chất lượng cuộc sống” (quality-of-life) và hiệu suất để hoàn thiện cấu hình của bạn.

Mở file /etc/sssd/sssd.conf và thêm các dòng sau vào mục [domain/...]:

[domain/ad.example.com]
...
# ================================
# QoL & PERFORMANCE TWEAKS
# ================================

# 1. Đặt shell mặc định là /bin/bash (thay vì /bin/sh)
default_shell = /bin/bash

# 2. Đặt template thư mục home (đẹp hơn)
# Đổi /home/[email protected] thành /home/user
override_homedir = /home/%u
fallback_homedir = /home/%u

# 3. Tối ưu hiệu suất cho mạng lớn (Tùy chọn)
# Buộc SSSD chỉ dùng DC tại site gần nhất (ví dụ: "Default-First-Site-Name")
ad_site = TenSiteCuaBan

# 4. Cấu hình tên đăng nhập ngắn (Chọn 1 trong 2 cách)

# Cách A (Phổ biến): Cho phép đăng nhập bằng "user" thay vì "[email protected]"
use_fully_qualified_names = False

# Cách B (Linh hoạt): Giữ tên đầy đủ, nhưng thêm 1 domain mặc định
# Cho phép "user" tự động thành "[email protected]"
# default_domain_suffix = ad.example.com

Giải thích:

use_fully_qualified_names = False: (Cách A) Cho phép bạn SSH bằng ssh user@vps_ip. Đây là cách đơn giản nhất.
default_domain_suffix: (Cách B) Là một giải pháp thay thế. Nếu bạn có nhiều domain tin cậy (trusted domains), bạn nên giữ use_fully_qualified_names = True và đặt tùy chọn này.
ad_site: Rất quan trọng trong môi trường doanh nghiệp có nhiều văn phòng. Nó giảm độ trễ mạng bằng cách buộc SSSD nói chuyện với Domain Controller gần nhất.

Áp dụng cấu hình và khắc phục sự cố

Sau khi chỉnh sửa file /etc/sssd/sssd.conf, bạn bắt buộc phải làm 2 việc sau:

Bước 1: Khởi động lại SSSD

sudo systemctl restart sssd

Dịch vụ SSSD phải được khởi động lại để đọc file .conf mới.

Bước 2: Xóa cache SSSD (Cực kỳ quan trọng)

SSSD lưu cache (bộ đệm) thông tin người dùng và nhóm để tăng tốc độ. Nếu bạn vừa thay đổi quyền truy cập (simple_allow_groups), bạn phải xóa cache cũ.

sudo sss_cache -E

Lệnh này sẽ xóa toàn bộ cache, buộc SSSD phải liên hệ lại với AD để lấy thông tin mới nhất.

Bước 3: Kiểm tra

Kiểm tra đăng nhập: Mở một cửa sổ terminal mới.
- Thử SSH bằng tài khoản thuộc nhóm được phép (ví dụ: ssh user_admin@vps_ip). (Phải thành công).
- Thử SSH bằng tài khoản không thuộc nhóm được phép. (Phải thất bại, báo “Permission denied”).
Kiểm tra Sudo:
- Đăng nhập bằng tài khoản admin (ở Bước 3).
- Chạy lệnh sudo whoami. Hệ thống phải yêu cầu mật khẩu (của user AD) và trả về root.

Các lỗi thường gặp (Troubleshooting)

Lỗi: SSSD không khởi động (Job failed to start)
- Nguyên nhân 1: Bạn gõ sai cú pháp trong file sssd.conf.
- Nguyên nhân 2: Quyền (permission) file sai.
- Giải pháp: Đảm bảo file /etc/sssd/sssd.conf có quyền là 600 và chủ sở hữu là root:root.
```
sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf
```
Lỗi: Vẫn đăng nhập được (dù đã cấm) hoặc không đăng nhập được (dù đã cho phép)
- Nguyên nhân: Do SSSD cache.
- Giải pháp: Chạy sudo sss_cache -E và thử lại.
Lỗi: Đăng nhập báo “Authentication failure” (dù đúng mật khẩu)
- Nguyên nhân: Lỗi Kerberos, 99% là do lệch thời gian.
- Giải pháp: Đảm bảo VPS và Domain Controller của bạn đồng bộ thời gian (dùng chrony). Kerberos không chấp nhận chênh lệch thời gian quá 5 phút. Nếu chrony đã đúng, hãy kiểm tra DNS, bạn có thể dùng các công cụ khắc phục sự cố DNS để xác minh.
Lỗi: id user@domain báo “no such user” (không tìm thấy user)
- Nguyên nhân: SSSD không thể liên lạc với AD hoặc có lỗi cấu hình sâu.
- Giải pháp: Bật gỡ lỗi (debug) SSSD. Sửa file sssd.conf, trong mục [domain/...] thêm debug_level = 9. Khởi động lại sssd và xem log chi tiết tại /var/log/sssd/sssd_ad.example.com.log. (Nhớ tắt debug_level sau khi sửa xong).

Câu hỏi thường gặp (FAQ)

1. Sự khác biệt giữa simple_allow_groups và ad_access_filter là gì?

Cả hai đều dùng để giới hạn ai được phép đăng nhập, nhưng khác nhau về độ phức tạp:

simple_allow_groups: (Khuyến nghị) Là cách đơn giản, dễ đọc. Bạn chỉ cần liệt kê tên các nhóm được phép (tạo một “whitelist”).
ad_access_filter: Là cách nâng cao, mạnh mẽ. Bạn phải viết một câu truy vấn LDAP (LDAP filter) phức tạp. Cách này chỉ cần thiết nếu bạn có quy tắc rất cụ thể (ví dụ: cho phép thành viên nhóm A VÀ cũng phải thuộc nhóm B).

2. Làm cách nào để giới hạn chỉ cho phép nhóm ‘Linux_Admins’ đăng nhập VPS?

Cách đơn giản và an toàn nhất là sử dụng simple_allow_groups. Mở file /etc/sssd/sssd.conf, tìm đến mục [domain/...] của bạn và thêm 2 dòng: access_provider = simple và simple_allow_groups = [email protected]. Sau đó, chạy sudo systemctl restart sssd và sudo sss_cache -E để áp dụng.

3. Làm cách nào để kiểm tra user AD có quyền đăng nhập không (trước khi thử SSH)?

Bạn có thể dùng công cụ sssctl (với quyền sudo hoặc root) để kiểm tra. Lệnh này sẽ cho bạn biết SSSD có cho phép user đăng nhập hay không, dựa trên các quy tắc access_provider bạn đã thiết lập: sudo sssctl user-checks [email protected]. Nếu thấy dòng “User is allowed to login”, nghĩa là cấu hình của bạn đã đúng.

4. Cấp quyền sudo cho nhóm AD (‘Domain Admins’) như thế nào là dễ nhất?

Cách dễ nhất là tạo file cấu hình sudo local. Chạy lệnh sudo visudo -f /etc/sudoers.d/ad_admins. Bên trong file, thêm dòng sau (lưu ý dấu % cho nhóm và dấu \ nếu tên nhóm có khoảng trắng): %Domain\ [email protected] ALL=(ALL) ALL. Lưu file lại, quyền sudo sẽ có hiệu lực cho lần đăng nhập tiếp theo của user.

5. sudo_provider = ad và sudo_provider = ldap khác gì nhau?

sudo_provider = ldap là cách cấu hình cũ hơn. sudo_provider = ad là cách làm hiện đại, được khuyến nghị khi id_provider của bạn cũng là ad. Nó cho phép SSSD tự động tìm quy tắc sudo bằng Global Catalog của AD mà không cần bạn chỉ định máy chủ LDAP cụ thể, giúp cấu hình đơn giản và linh hoạt hơn.

6. Làm sao để đăng nhập bằng tên ngắn (user) thay vì ([email protected])?

Bạn có thể làm điều này bằng cách thêm một dòng vào file /etc/sssd/sssd.conf trong mục [domain/...]: use_fully_qualified_names = False. Sau khi lưu file, hãy nhớ chạy sudo systemctl restart sssd và sudo sss_cache -E.

7. Tôi đã thay đổi sssd.conf nhưng không thấy tác dụng?

Bạn gần như chắc chắn đã quên một trong hai bước bắt buộc sau khi sửa file sssd.conf:

Khởi động lại dịch vụ: sudo systemctl restart sssd
Xóa cache SSSD để buộc nó đọc lại quyền mới: sudo sss_cache -E

8. Tại sao tôi phải dùng sss_cache -E sau khi thay đổi?

SSSD lưu trữ (cache) thông tin người dùng và nhóm trong một cơ sở dữ liệu cục bộ để tăng tốc độ. Khi bạn thay đổi quyền trong sssd.conf (ví dụ: thêm nhóm vào simple_allow_groups), SSSD không tự động biết điều đó; nó vẫn đọc từ cache cũ. Lệnh sss_cache -E buộc SSSD xóa toàn bộ cache và tải lại thông tin mới nhất từ Active Directory. Điều này đảm bảo các quy tắc truy cập mới của bạn được áp dụng ngay lập tức.

Kết luận

Bạn đã hoàn tất cấu hình SSSD nâng cao! VPS Linux của bạn giờ đây không chỉ là một thành viên của AD, mà còn là một thành viên được bảo vệ chặt chẽ.

Bằng cách giới hạn đăng nhập (simple_allow_groups) và phân quyền sudo chi tiết (/etc/sudoers.d/), bạn đã áp dụng các nguyên tắc bảo mật then chốt, đảm bảo chỉ những quản trị viên có thẩm quyền mới có thể truy cập và quản lý máy chủ. Việc cấu hình Sudo tập trung là một giải pháp tuyệt vời cho các môi trường doanh nghiệp lớn, giúp bạn quản lý hàng trăm VPS từ một nơi duy nhất.

Về ZingServer.com

Blog

Câu hỏi thường gặp

Liên hệ ZingServer

Chương trình Affiliate

Tài liệu API

Điều khoản chính sách

Locations

Cloud VPS Server

Máy chủ vật lý

VPS Windows

VPS Hosting

Proxy dân cư, Datacenter

Về ZingServer.com

Blog

Câu hỏi thường gặp

Liên hệ ZingServer

Chương trình Affiliate

Tài liệu API

Điều khoản chính sách

Locations

Cloud VPS Server

Máy chủ vật lý

VPS Windows

VPS Hosting

Proxy dân cư, Datacenter

Hướng dẫn sử dụng VPS

Điều kiện tiên quyết (Quan trọng)

Cấu hình SSSD: Giới hạn đăng nhập AD (Access Control)

Cách 1: Dùng simple_allow_groups (Đơn giản & khuyến nghị)

Cách 2: Dùng ad_access_filter (Nâng cao & linh hoạt)

Cách 3: Dùng lệnh realm permit (Cách của “realmd”)

Cấu hình cấp quyền Sudo cho nhóm AD

Cách 1: Cấu hình Local (Phổ biến & linh hoạt nhất)

Cách 2: Cấu hình tập trung (Quản lý Sudo từ AD)

Tinh chỉnh SSSD: Tối ưu trải nghiệm và hiệu suất

Áp dụng cấu hình và khắc phục sự cố

Bước 1: Khởi động lại SSSD

Bước 2: Xóa cache SSSD (Cực kỳ quan trọng)

Bước 3: Kiểm tra

Các lỗi thường gặp (Troubleshooting)

Câu hỏi thường gặp (FAQ)

Kết luận

Tài liệu tham khảo

Bài viết liên quan

Về ZingServer.com

Blog

Câu hỏi thường gặp

Liên hệ ZingServer

Chương trình Affiliate

Tài liệu API

Điều khoản chính sách

Locations

Cloud VPS Server

Máy chủ vật lý

VPS Windows

VPS Hosting

Proxy dân cư, Datacenter

Cách 1: Dùng `simple_allow_groups` (Đơn giản & khuyến nghị)

Cách 2: Dùng `ad_access_filter` (Nâng cao & linh hoạt)

Cách 3: Dùng lệnh `realm permit` (Cách của “realmd”)