Kết nối Linux Server với Active Directory bằng SSSD và Realmd: Hướng dẫn từng bước

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

Việc khởi tạo các thông tin đăng nhập cục bộ riêng lẻ trên 25 hay 50 máy chủ tiêu tốn hàng giờ vận hành. Mỗi khi tuyển một kỹ sư mới, bạn lại phải tạo tài khoản, gán UID và phân phối SSH public key tới từng máy chủ. Đến khi có nhân sự nghỉ việc, việc rà soát và thu hồi quyền truy cập trên từng máy riêng biệt trở thành một công việc dễ xảy ra sai sót.

Việc gia nhập dàn máy chủ Linux vào Microsoft Active Directory (AD) sẽ loại bỏ hoàn toàn gánh nặng này. Các kỹ sư có thể đăng nhập bằng chính tài khoản domain sẵn có. Đội ngũ bảo mật quản lý tài khoản và chính sách truy cập từ một bảng điều khiển thư mục duy nhất. Dưới đây là cách kết nối các hệ thống Ubuntu, Debian và họ RHEL với AD bằng cách sử dụng realmd và sssd.

Bắt đầu nhanh (dưới 5 phút)

Giả sử Domain Controller (DC) của bạn có địa chỉ IP 192.168.10.15 và quản lý domain corp.example.com. Máy chủ Linux cần kết nối thông suốt tới DC này qua các cổng tiêu chuẩn: DNS (53), Kerberos (88) và LDAP (389).

1. Cài đặt các package cần thiết

Trên Ubuntu 22.04 hoặc Debian 12, hãy cập nhật apt cache và cài đặt các tiện ích kết nối:

sudo apt update
sudo apt install -y realmd sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

Trên RHEL 9, Rocky Linux 9 hoặc AlmaLinux 9, cài đặt các package tương đương bằng dnf:

sudo dnf install -y realmd sssd adcli samba-common-tools oddjob oddjob-mkhomedir krb5-workstation

2. Dò tìm domain của bạn

Kiểm tra xem máy Linux có phân giải được các bản ghi SRV và kết nối tới domain controller hay không:

realm discover corp.example.com

Kết quả trả về sẽ liệt kê tên domain tìm thấy, phần mềm client được khuyến nghị (sssd) và các dependency còn thiếu nếu có. Nếu lệnh dò tìm bị treo hoặc báo lỗi NXDOMAIN, hãy kiểm tra /etc/resolv.conf. Máy chủ của bạn phải trỏ trực tiếp đến DC hoặc một DNS resolver nội bộ có thể xử lý các bản ghi AD.

3. Gia nhập domain

Xác thực bằng một tài khoản có quyền tạo computer object trong AD:

sudo realm join -U srv-join-admin corp.example.com

Nhập mật khẩu của service account khi được nhắc. Lệnh sẽ thực thi âm thầm khi thành công và tạo machine account trong container mặc định CN=Computers.

4. Kiểm tra tra cứu người dùng

Xác nhận rằng SSSD có thể lấy dữ liệu định danh trực tiếp từ AD:

id [email protected]

Gia nhập thành công sẽ hiển thị các thuộc tính POSIX như uid=1844800500([email protected]) gid=1844800513(domain [email protected]) groups=.... SSSD tự động ánh xạ các ID số này thông qua thuật toán ánh xạ.

Nguyên lý hoạt động chi tiết

Các bước gia nhập nhanh giúp người dùng xác thực được ngay. Tuy nhiên, việc hiểu rõ các thành phần cốt lõi sẽ giúp quá trình bảo trì production và xử lý sự cố trở nên đơn giản hơn nhiều.

Mối liên kết giữa realmd, SSSD và Kerberos

Việc tích hợp domain dựa trên ba tầng riêng biệt:

  • realmd: Tiện ích điều phối D-Bus. Nó xử lý quá trình bắt tay ban đầu, liên hệ với DC thông qua adcli, tạo các mục keytab và ghi cấu hình SSSD cơ bản.
  • sssd: Daemon chạy ngầm xử lý các truy vấn định danh NSS và yêu cầu xác thực PAM. Nó lưu cache các truy vấn thư mục cục bộ trong cơ sở dữ liệu LDB tại /var/lib/sss/db/, nhờ đó người dùng vẫn có thể đăng nhập khi mạng WAN gặp sự cố.
  • Kerberos (krb5) & adcli: Kerberos phụ trách cấp ticket (TGT) và xác thực mã hóa. Trong khi đó, adcli sẽ định kỳ xoay vòng mật khẩu của host machine account mỗi 30 ngày với AD.

Tinh chỉnh /etc/sssd/sssd.conf

Quá trình khởi tạo ban đầu sẽ tạo file /etc/sssd/sssd.conf với quyền nghiêm ngặt (mode 0600, thuộc sở hữu của root:root). Chỉnh sửa file này để tùy biến hành vi đăng nhập:

sudo nano /etc/sssd/sssd.conf

Dưới đây là cấu hình production đã được kiểm nghiệm thực tế:

[sssd]
domains = corp.example.com
config_file_version = 2
services = nss, pam

[domain/corp.example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = CORP.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u
ad_domain = corp.example.com
use_fully_qualified_names = False
ldap_id_mapping = True
access_provider = ad

Thiết lập use_fully_qualified_names = False giúp công việc hằng ngày thuận tiện hơn. Người dùng có thể đăng nhập bằng jdoe thay vì [email protected], duy trì tính tương thích với các script và công cụ thường gặp lỗi khi xử lý ký tự @. Thiết lập fallback_homedir = /home/%u giúp đường dẫn thư mục home gọn gàng và quen thuộc.

Khởi động lại daemon sau khi lưu bất kỳ thay đổi cấu hình nào:

sudo systemctl restart sssd

Tự động tạo thư mục home khi đăng nhập lần đầu

Các đối tượng trong AD không có sẵn đường dẫn thư mục home chuẩn của Linux. Nếu không có hook tự động tạo, người dùng sẽ gặp cảnh báo: No home directory, logging in with HOME=/.

Trên Ubuntu và Debian, hãy kích hoạt module tạo thư mục home trong PAM:

sudo pam-auth-update --enable mkhomedir

Trên RHEL 9 và Rocky Linux, bật tính năng này bằng authselect và khởi chạy service hỗ trợ:

sudo authselect select sssd with-mkhomedir --force
sudo systemctl enable --now oddjobd

Kiểm soát truy cập trên môi trường Production

Giới hạn quyền SSH theo các group được ủy quyền

Mặc định sau khi vừa gia nhập domain, bất kỳ user AD nào xác thực thành công cũng có thể mở phiên đăng nhập tương tác. Trên các node cơ sở dữ liệu hoặc máy chủ ứng dụng production, bạn nên giới hạn quyền truy cập chỉ cho các nhóm vận hành được chỉ định.

Sử dụng realm permit để kiểm soát các đăng nhập được cấp phép:

# Chặn tất cả tài khoản domain theo mặc định
sudo realm deny --all

# Cho phép một nhóm bảo mật Active Directory cụ thể
sudo realm permit -g "Linux Engineers"

# Thêm vào whitelist một tài khoản sự cố khẩn cấp (break-glass)
sudo realm permit srv-auditor

Lệnh này sẽ chèn một bộ lọc vào tham số ad_access_filter hoặc simple_allow_groups trong /etc/sssd/sssd.conf. Các tài khoản không nằm trong whitelist sẽ bị từ chối ở giai đoạn PAM với lỗi access denied.

Phân quyền sudo cho các group trong AD

Đừng bao giờ dán trực tiếp các tài khoản domain vào file /etc/sudoers. Thay vào đó, hãy tạo một file cấu hình riêng biệt trong thư mục /etc/sudoers.d/.

Mở một file cấu hình riêng biệt kèm kiểm tra cú pháp:

sudo visudo -f /etc/sudoers.d/ad-linux-engineers

Thêm quy tắc sau, dùng dấu gạch chéo ngược (backslash) để thoát các khoảng trắng:

%Linux\ Engineers ALL=(ALL:ALL) ALL

Nếu bạn giữ nguyên use_fully_qualified_names = True trong SSSD, hãy cung cấp đầy đủ phần hậu tố realm:

%Linux\ [email protected] ALL=(ALL:ALL) ALL

Lưu file và thoát. visudo sẽ kiểm tra cú pháp trước khi ghi xuống đĩa, giúp tránh các lỗi gõ sai có thể làm hỏng quyền sudo trên toàn bộ hệ thống.

Xử lý sự cố và kinh nghiệm vận hành

Lưu ý độ lệch đồng hồ (clock skew) trong Kerberos

Kerberos sẽ từ chối ticket nếu đồng hồ giữa client và DC chênh lệch quá 300 giây (5 phút). Sự lệch pha này sẽ gây lỗi xác thực ngay lập tức với thông báo: Clock skew too great.

Đồng bộ thời gian của máy chủ bằng chrony với PDC emulator nội bộ hoặc thiết bị NTP local. Kiểm tra trạng thái đồng bộ bằng:

chronyc sources -v
timedatectl status

Xóa cache khi thông tin group bị lỗi thời

SSSD lưu trữ cache các đối tượng định danh để giảm tải các kết nối mạng tới domain controller. Nếu bạn thêm một kỹ sư vào AD group Linux Engineers trong Active Directory Users and Computers (ADUC), máy chủ cục bộ có thể sẽ không nhận diện được ngay trong vài phút. Hãy xóa cache cục bộ để cập nhật tức thì:

sudo sss_cache -E
sudo systemctl restart sssd

Bảo vệ phiên đăng nhập trong quá trình triển khai

Những thay đổi về xác thực sẽ tác động trực tiếp đến chuỗi xử lý PAM. Một chỉ thị cấu hình sai vị trí có thể khiến bạn bị khóa hoàn toàn khỏi phiên SSH.

Hãy duy trì ba thói quen phòng ngừa sau khi can thiệp vào xác thực trên môi trường production:

  • Luôn giữ một terminal root đang hoạt động ở một cửa sổ riêng cho đến khi xác nhận mọi thứ hoạt động bình thường.
  • Đảm bảo một tài khoản quản trị cục bộ trong /etc/passwd có mật khẩu hợp lệ và quyền sudo hoạt động tốt.
  • Theo dõi liên tục (tail) file /var/log/auth.log (Ubuntu/Debian) hoặc /var/log/secure (RHEL/Rocky) trong các lần đăng nhập thử nghiệm để phát hiện ngay các module PAM bị lỗi và mã từ chối Kerberos.
Share: