Site icon ZingServer

Di chuyển Winbind sang SSSD: Hướng dẫn an toàn UID/GID

Team ZingServer
Di chuyển Winbind sang SSSD Hướng dẫn an toàn UIDGID

Di chuyển Winbind sang SSSD Hướng dẫn an toàn UIDGID

Bạn đang vận hành một VPS Linux đã join AD bằng Winbind? Bạn có mệt mỏi với hiệu suất truy vấn chậm? Lệnh id username mất vài giây mới phản hồi? Hay bạn lo lắng vì Winbind không hỗ trợ đăng nhập offline khi VPS mất kết nối?

SSSD (System Security Services Daemon), thường được cấu hình qua realmd (xem hướng dẫn join bằng realmd), là giải pháp nâng cấp hiện đại, giải quyết triệt để các vấn đề này. Nếu bạn chưa rõ ưu nhược điểm, hãy xem bài so sánh SSSD vs Winbind của chúng tôi.

Việc di chuyển Winbind sang SSSD là một “ca phẫu thuật” hệ thống. Nó đòi hỏi sự cẩn trọng tuyệt đối. Rủi ro lớn nhất là làm lệch UID/GID của người dùng Active Directory. Hãy tưởng tượng kịch bản thảm họa: User đăng nhập thành công nhưng mất toàn bộ quyền sở hữu (owner) file của chính mình.

Bài viết này không phải là một hướng dẫn “cài đặt” SSSD đơn thuần. Đây là một lộ trình “di chuyển” an toàn đã được kiểm chứng. Chúng tôi sẽ hướng dẫn bạn chẩn đoán hệ thống Winbind hiện tại. Sau đó, bạn sẽ chọn 1 trong 4 lộ trình di chuyển phù hợp, đảm bảo UID/GID được bảo toàn 100%.

Tại sao SSSD là bản nâng cấp đáng giá?

So với Winbind (một phần của Samba), SSSD mang lại lợi ích vượt trội cho một VPS hoặc máy chủ Linux hiện đại tích hợp AD.

Bảng so sánh nhanh: SSSD vs Winbind

Tính năng Winbind (Một phần của Samba) SSSD (Daemon độc lập)
Mục đích chính Chia sẻ file (Samba) & Xác thực Quản lý Định danh & Xác thực
Caching Offline Rất hạn chế hoặc không có. Rất mạnh. Tính năng cốt lõi.
Hiệu suất (Lệnh id) Chậm (Phải hỏi DC) Cực nhanh (Đọc từ cache)
Cấu hình Phức tạp (smb.conf, krb5…) Đơn giản (tự động bởi realmd)
Use Case tốt nhất VPS làm File Server 90% VPS (Web, App, DB, SSH)

Cảnh báo “sống còn” trước khi bắt đầu

Trước khi gõ bất kỳ lệnh nào, bạn phải nắm rõ 2 rủi ro nghiêm trọng sau đây. Bỏ qua chúng có thể phá vỡ hệ thống của bạn.

Cảnh báo 1: Hiểu đúng về cơ chế ID Mapping của SSSD (ldap_id_mapping)

Cả Winbind và SSSD đều phải “dịch” SID của user AD thành UID Linux.

Đây là lỗi nguy hiểm: Nếu backend Winbind của bạn là rid (Lộ trình A), nhưng bạn lại bật ldap_id_mapping = true trong SSSD, bộ máy mapping khác biệt của SSSD sẽ được kích hoạt. Nó sẽ tạo ra các UID/GID mới, không tương thích với rid, và phá vỡ file permission.

Quy tắc vàng:

Cảnh báo 2: Server của bạn có phải là Samba File Server không?

Bài viết này tập trung vào di chuyển Winbind trên các VPS chỉ dùng để xác thực (cho phép user SSH, sudo).

Nếu VPS của bạn đồng thời là một Samba File Server đang hoạt động (chia sẻ thư mục /data cho user Windows), việc di chuyển cực kỳ phức tạp. Chạy SSSD và Samba trên cùng một máy chủ để chia sẻ file có thể gây xung đột về ID mapping và yêu cầu cấu hình sssd-cifs-idmap-plugin đặc biệt.

Khuyến nghị: Nếu VPS của bạn là File Server đang hoạt động, hãy dừng lại. Bài viết này không bao quát trường hợp đó. Hãy tìm một lộ trình chuyên biệt hơn.

Kế hoạch di chuyển an toàn (4 Bước)

Đây là kế hoạch tổng thể. Đừng vội thực thi, hãy đọc hết các bước. Kế hoạch này được thiết kế để đảm bảo bạn không làm mất dữ liệu hoặc quyền sở hữu file.

Bước 1: Chuẩn bị (Điều kiện tiên quyết)

Trước khi di chuyển, hãy đảm bảo hệ thống của bạn đáp ứng các yêu cầu sau:

Bước 2: Sao lưu (Backup) toàn bộ

Đây là “dù cứu sinh” của bạn. Nếu có bất kỳ lỗi nào, bạn có thể dùng bản sao lưu này để quay lại trạng thái Winbind ban đầu. Hãy backup tất cả các file cấu hình liên quan.

# Tạo thư mục backup an toàn
sudo mkdir /root/winbind_backup
sudo cp /etc/samba/smb.conf /root/winbind_backup/
sudo cp /etc/nsswitch.conf /root/winbind_backup/
sudo cp /etc/krb5.conf /root/winbind_backup/

# Backup toàn bộ cấu hình PAM
sudo cp -r /etc/pam.d /root/winbind_backup/

Bước 3: Chẩn đoán (Bước quan trọng nhất)

Bây giờ, hãy mở file cấu hình Winbind của bạn. Đây là bước sẽ quyết định lộ trình di chuyển của bạn.

sudo nano /etc/samba/smb.conf

Tìm các dòng cấu hình idmap config *. Bạn cần tìm chính xác dòng backend = ???. Nó thường nằm trong phần [global].

[global]
...
# Tìm các dòng như thế này
idmap config * : backend = ???
idmap config * : range = ...
...

Bước 4: Chọn lộ trình di chuyển

Dựa vào giá trị backend = ??? bạn tìm được, hãy chọn 1 trong 4 lộ trình dưới đây. Đừng làm sai lộ trình!

Lộ trình A (Dễ): Di chuyển từ backend = rid

Tin tốt: Đây là trường hợp phổ biến và dễ nhất. Winbind đang dùng thuật toán rid (lấy phần cuối của SID) để tạo UID/GID.

SSSD (khi dùng id_provider = ad và không set cờ ldap_id_mapping) cũng dùng chính xác thuật toán này.

Chúng ta chỉ cần đảm bảo SSSD được cấu hình đúng để sao chép lại logic đó.

Thách thức: realm join có thể tự động cấu hình SSSD với ldap_id_mapping = true (mặc định), điều này không phù hợp với lộ trình này. Bạn cần kiểm tra và điều chỉnh cấu hình sau khi join.

Các bước thực thi (Lộ trình A):

  1. Cài đặt SSSD & công cụ: Bạn cần cài sssd và các công cụ hỗ trợ (realmd, adcli). 
    # RHEL/CentOS/Rocky
sudo dnf install sssd-ad sssd-tools adcli realmd krb5-workstation

# Ubuntu/Debian
sudo apt update && sudo apt install sssd-ad sssd-tools adcli realmd krb5-user packagekit
  2. Join Domain bằng realm: Lệnh realm join sẽ tự động phát hiện AD. Nó tự động cấu hình SSSD và PAM cho bạn. 
    sudo realm join YOURDOMAIN.COM -U 'Administrator'
# Nhập mật khẩu Administrator khi được hỏi
  3. Kiểm tra “chốt hạ”: Mở file /etc/sssd/sssd.conf mà realm vừa tạo ra. Kiểm tra kỹ trong phần [domain/yourdomain.com].
    • Bắt buộc phải đảm bảo dòng ldap_id_mapping KHÔNG TỒN TẠI (không được set).
    • Nếu nó không tồn tại, bạn đã an toàn.
    • Nếu realm tự động đặt ldap_id_mapping = true hoặc ldap_id_mapping = false, hãy xóa hoàn toàn dòng đó đi (hoặc comment nó lại bằng dấu #) ngay lập tức. Đây là lỗi phổ biến gây lệch UID.
  4. Chuyển sang bước hoàn tất: Giờ bạn đã sẵn sàng. Hãy chuyển đến Phần 8: Hoàn tất di chuyển.

Lộ trình B (Dễ): Di chuyển từ backend = ad

Tin tuyệt vời: Đây là trường hợp lý tưởng. Cấu hình này có nghĩa là Active Directory của bạn đã được mở rộng Schema (có thuộc tính POSIX uidNumber, gidNumber).

Winbind không “tạo” UID. Nó chỉ đơn giản là “đọc” các thuộc tính này có sẵn trong AD.

Chúng ta chỉ cần ra lệnh cho SSSD làm điều tương tự.

Các bước thực thi (Lộ trình B):

  1. Cài đặt SSSD & công cụ: (Giống hệt lộ trình A). 
    # RHEL/CentOS/Rocky
sudo dnf install sssd-ad sssd-tools adcli realmd krb5-workstation

# Ubuntu/Debian
sudo apt update && sudo apt install sssd-ad sssd-tools adcli realmd krb5-user packagekit
  2. Join Domain với cờ automatic-id-mapping=no: Đây là cờ quan trọng nhất cho lộ trình này.
    Cờ này ra lệnh cho realm và SSSD: “Đừng tự tạo UID. Hãy đọc thuộc tính uidNumber có sẵn từ AD.” 
    sudo realm join --automatic-id-mapping=no YOURDOMAIN.COM -U 'Administrator'
# Nhập mật khẩu Administrator khi được hỏi
  3. Kiểm tra “chốt hạ”: Mở file /etc/sssd/sssd.conf. Bạn sẽ thấy ldap_id_mapping = false (hoặc không có dòng nào). Đây là cấu hình chính xác.
    Nó xác nhận SSSD đang ở chế độ “đọc” thuộc tính, không phải “tạo” thuộc tính.
  4. Chuyển sang bước hoàn tất: Giờ bạn đã sẵn sàng. Hãy chuyển đến Phần 8: Hoàn tất di chuyển.

Lộ trình C (Trung bình): Di chuyển từ autorid

Chẩn đoán: File smb.conf của bạn có idmap config * : backend = autorid và một range (ví dụ: 10000-999999).

Tin tốt: autorid tạo UID/GID bằng cách băm (hash) SID của user. SSSD có một chế độ tương thích (compatibility mode) để “bắt chước” chính xác thuật toán băm này.

Chúng ta không cần xuất/nhập thủ công vào AD. Chúng ta chỉ cần cấu hình SSSD cho đúng.

Các bước thực thi (Lộ trình C):

  1. Ghi lại dải số (Range):
    • Nhìn vào file smb.conf của bạn. Ghi lại chính xác dải số.
    • Ví dụ: idmap config * : range = 10000-999999. (min=10000, max=999999).
  2. Cài đặt SSSD & công cụ: (Giống lộ trình A). 
    # RHEL/CentOS/Rocky
sudo dnf install sssd-ad sssd-tools adcli realmd krb5-workstation

# Ubuntu/Debian
sudo apt update && sudo apt install sssd-ad sssd-tools adcli realmd krb5-user packagekit
  3. Join Domain bằng realm:
    • Cứ chạy realm join như bình thường. 
      sudo realm join YOURDOMAIN.COM -U 'Administrator'
# Nhập mật khẩu Administrator khi được hỏi
    • Lệnh này sẽ tạo ra file /etc/sssd/sssd.conf (nhưng chưa chuẩn cho autorid).
  4. Cấu hình SSSD “bắt chước” autorid (Rất quan trọng):
    • Mở file SSSD: sudo nano /etc/sssd/sssd.conf.
    • Tìm đến phần [domain/yourdomain.com].
    • Thêm (hoặc sửa) 4 dòng sau. Đây chính là “chìa khóa”: 
      [domain/yourdomain.com]
...
ldap_id_mapping = true
ldap_idmap_autorid_compat = true
ldap_idmap_range_min = 10000
ldap_idmap_range_max = 999999
...
    • Giải thích:
      • ldap_id_mapping = true: Bật bộ máy mapping của SSSD.
      • ldap_idmap_autorid_compat = true: Ra lệnh cho bộ máy “bắt chước” thuật toán autorid.
      • ldap_idmap_range_min/max: Đảm bảo SSSD hash vào đúng dải số Winbind đã dùng (thay 10000 và 999999 bằng giá trị bạn ghi ở Bước 1).
  5. Chuyển sang bước hoàn tất:

Lộ trình D (Phức tạp): Di chuyển từ tdb

Cảnh báo: Đây là kịch bản phức tạp nhất, thường gặp ở các hệ thống rất cũ. backend = tdb có nghĩa là UID/GID của bạn được lưu trong một file database (.tdb) cục bộ trên VPS.

Các UID/GID này không có tính thuật toán. Chúng được cấp phát ngẫu nhiên hoặc tuần tự khi user/group được truy cập lần đầu. AD hoàn toàn không biết về các UID/GID này. Bạn KHÔNG THỂ di chuyển an toàn chỉ bằng cách cài SSSD. Chúng ta phải “nâng cấp” AD bằng tay, ép nó lưu trữ các UID/GID này.

Các bước thực thi (Lộ trình D):

Đây là quy trình 3 giai đoạn. Bạn phải làm theo thứ tự.

Giai đoạn 1: Trích xuất (Export) UID/GID từ Winbind tdb

Trên VPS Winbind cũ, bạn cần trích xuất bản đồ ánh xạ username -> UID và groupname -> GID.

# Lấy danh sách user và UID của họ
getent passwd | grep 'YOURDOMAIN\' > /root/user_export.txt

# Lấy danh sách group và GID của họ
getent group | grep 'YOURDOMAIN\' > /root/group_export.txt

Mở các file này. Bạn sẽ có dữ liệu thô. Hãy lọc ra tên user, UID (cột 3), và GID chính (cột 4).

Ví dụ user_export.txt: YOURDOMAIN\nva:*:18234:10001:... (User nva, UID 18234, GID chính 10001)

Ví dụ group_export.txt: YOURDOMAIN\domain users:*:10001: (Group domain users, GID 10001)

Giai đoạn 2: Điền (Populate) UID/GID vào Active Directory

Bạn phải chuyển sang máy Domain Controller (Windows Server).

Mở PowerShell ISE (với quyền Admin). Đảm bảo “Active Directory module for Windows PowerShell” đã được cài đặt.

Với dữ liệu bạn vừa trích xuất, hãy dùng lệnh Set-ADUser và Set-ADGroup để ghi các giá trị này vào thuộc tính POSIX của AD (uidNumber, gidNumber).

# Ví dụ cho user 'nva' có UID 18234 và GID chính 10001
# (-Replace dùng nếu thuộc tính đã có, -Add nếu chưa có)
Set-ADUser -Identity nva -Replace @{'uidNumber'='18234'; 'gidNumber'='10001'}

# Ví dụ cho group 'domain users' có GID 10001
Set-ADGroup -Identity 'Domain Users' -Replace @{'gidNumber'='10001'}

Đây là bước thủ công và tốn thời gian, nhưng bắt buộc phải làm. Bạn phải lặp lại cho tất cả các user/group quan trọng cần di chuyển.

Giai đoạn 3: Di chuyển (Giống lộ trình B)

Sau khi AD đã được điền đầy đủ uidNumber và gidNumber, hệ thống của bạn về cơ bản đã giống lộ trình B.

Quay lại VPS Linux và thực hiện chính xác các bước của lộ trình B:

  1. Cài realmd (Nếu chưa cài).
  2. Chạy sudo realm join --automatic-id-mapping=no YOURDOMAIN.COM -U 'Administrator'.

SSSD sẽ đọc các UID/GID bạn vừa điền vào AD, đảm bảo khớp 100% với UID/GID cũ của tdb.

Giờ bạn đã sẵn sàng. Hãy chuyển đến Phần 8: Hoàn tất di chuyển.

Hoàn tất di chuyển (“Cắt” Winbind, “Ghép” SSSD)

Bạn chỉ thực hiện các bước này sau khi đã hoàn thành một trong 4 lộ trình (A, B, C, hoặc D) và SSSD đã được cấu hình (ví dụ, realm join đã chạy và sssd.conf đã được kiểm tra/chỉnh sửa).

“Cắt” Winbind

  1. Dừng và vô hiệu hóa Winbind & Samba:
     
    sudo systemctl stop winbind smbd nmbd
sudo systemctl disable winbind smbd nmbd
  2. Gỡ Winbind khỏi NSS (Name Service Switch):
    • Mở /etc/nsswitch.conf (dùng file backup để đối chiếu).
    • Tìm và xóa winbind khỏi các dòng passwd: và group:.
    • Trước (ví dụ): passwd: files systemd winbind
    • Sau: passwd: files systemd (Chúng ta sẽ thêm sss ở bước sau).
  3. Gỡ Winbind khỏi PAM (Cách an toàn):
    • RHEL/CentOS/Rocky (dùng authselect):
       
      # Quay về profile sssd (nó sẽ tự loại bỏ winbind)
sudo authselect select sssd with-mkhomedir --force
sudo authselect apply-changes
    • Ubuntu/Debian (dùng pam-auth-update):
       
      sudo pam-auth-update --remove winbind

“Ghép” SSSD

  1. Kích hoạt SSSD trong NSS (nếu realm chưa làm):
    • Mở /etc/nsswitch.conf.
    • Thêm sss vào sau files.
    • Sau: passwd: files sss systemd và group: files sss systemd
  2. Kích hoạt SSSD trong PAM (nếu realm hoặc authselect chưa làm):
    • RHEL/CentOS/Rocky: (Lệnh authselect ở trên thường đã đủ).
    • Ubuntu/Debian:
       
      sudo pam-auth-update --enable sssd
sudo pam-auth-update --enable mkhomedir
# (mkhomedir để tự tạo thư mục /home khi user AD đăng nhập lần đầu)
  3. Khởi động và kích hoạt SSSD:
     
    sudo systemctl enable sssd
sudo systemctl restart sssd
# Dùng restart thay vì start để đảm bảo cấu hình mới được áp dụng

Kiểm tra (Giờ G) và khắc phục sự cố

Đây là thời điểm quan trọng nhất để xác nhận “ca phẫu thuật” thành công.

Kiểm tra ID Mapping

  1. Lấy UID/GID Winbind cũ:
    • Tham khảo file backup /root/winbind_backup/smb.conf.
    • Tốt nhất là bạn nên có ảnh chụp hoặc ghi lại kết quả id username trước khi di chuyển.
  2. Kiểm tra SSSD:
    • Xóa cache SSSD để buộc nó lấy dữ liệu mới từ AD (hoặc từ cache autorid của SSSD). 
      sudo sss_cache -E
    • Kiểm tra một user AD (dùng tên đầy đủ lần đầu): 
      id username@yourdomain.com
  3. So sánh:
    • UID và GID trả về từ SSSD phải khớp 100% với UID/GID cũ của Winbind.
  4. Kiểm tra thực tế:
    • Nếu khớp, hãy thử SSH bằng tài khoản AD: ssh username@localhost (hoặc ssh username@yourdomain.com@localhost nếu use_fully_qualified_names = true).
    • Kiểm tra quyền sở hữu file: ls -l /home/username. Tên user phải hiển thị chính xác, không phải là một con số UID.

Khắc phục sự cố

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

1. Tại sao tôi nên di chuyển từ Winbind sang SSSD?

SSSD mang lại hiệu suất tốt hơn (nhờ caching), cho phép đăng nhập offline khi mất kết nối DC, cấu hình đơn giản hơn và bảo mật hơn Winbind.

2. Rủi ro lớn nhất khi di chuyển là gì?

Rủi ro lớn nhất là làm lệch UID/GID của người dùng AD, khiến họ mất quyền sở hữu file. Điều này xảy ra nếu SSSD không được cấu hình để sử dụng cùng cơ chế mapping ID như Winbind.

3. Làm sao tôi biết mình nên theo lộ trình A, B, C hay D?

Bạn cần chẩn đoán file /etc/samba/smb.conf của mình và tìm dòng idmap config * : backend = ???. Giá trị của backend (là rid, ad, autorid, hay tdb) sẽ quyết định lộ trình chính xác bạn cần theo.

4. Tôi có thể dùng lệnh realm join để di chuyển không?

Có, realm join là công cụ chính, nhưng bạn phải cẩn thận. realm join thường tạo cấu hình SSSD với ldap_id_mapping = true mặc định, điều này sai cho lộ trình A/B/D (rid/ad/tdb). Bạn bắt buộc phải kiểm tra và sửa file /etc/sssd/sssd.conf sau khi join theo hướng dẫn của từng lộ trình.

5. Nếu VPS của tôi cũng là Samba File Server thì sao?

Bài viết này không áp dụng cho trường hợp đó. Di chuyển Winbind trên một Samba File Server đang hoạt động rất phức tạp và có thể gây xung đột. Bạn cần tìm hướng dẫn chuyên biệt khác.

Kết luận

Việc di chuyển Winbind sang SSSD là một nâng cấp quan trọng, giúp hiện đại hóa hệ thống Linux tích hợp AD của bạn.

Bằng cách “chẩn đoán” chính xác idmap backend (rid, ad, autorid, hay tdb) trước khi hành động, bạn đã có thể chọn đúng lộ trình và tránh được rủi ro lớn nhất là làm lệch UID/GID.

Giờ đây, VPS của bạn đã được hưởng lợi từ khả năng cache, đăng nhập offline và hiệu suất vượt trội của SSSD, trong khi vẫn bảo toàn 100% dữ liệu và quyền sở hữu file của người dùng.

Tài liệu tham khảo

Exit mobile version