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

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%.

Nội dung chính

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.

Hiệu suất: SSSD cache thông tin user và group rất thông minh. Các lệnh id hay getent passwd trả về kết quả gần như tức thời, không còn độ trễ.
Đăng nhập Offline: Đây là tính năng “sát thủ” của SSSD. Nó cache thông tin xác thực an toàn. Điều này cho phép người dùng đăng nhập ngay cả khi VPS mất kết nối đến Domain Controller. Winbind không thể làm điều này.
Quản lý: Toàn bộ cấu hình SSSD nằm gọn trong file /etc/sssd/sssd.conf. Nó rõ ràng và dễ quản lý hơn file smb.conf phức tạp của Winbind.
Bảo mật & hiện đại: SSSD được thiết kế ưu tiên Kerberos (Kerberos-first). Nó tránh các giao thức fallback cũ và kém an toàn, phù hợp với tiêu chuẩn bảo mật hiện đại.

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.

Winbind có các cơ chế “dịch” riêng, được cấu hình qua tham số backend trong smb.conf (ví dụ: rid, ad, autorid, tdb).
SSSD cũng có một bộ máy “dịch” (ID mapping engine) riêng của nó. Bộ máy này được kích hoạt bởi cờ ldap_id_mapping = true.

Đâ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:

Với lộ trình A (rid), cờ này BẮT BUỘC PHẢI ĐỂ TRỐNG (KHÔNG SET). Khi không được set, SSSD (với id_provider = ad) sẽ tự động dùng thuật toán mapping mặc định (dựa trên objectSID) tương thích 100% với rid.
Với lộ trình B (ad), cờ này BẮT BUỘC phải là false. SSSD sẽ dùng thuật toán tương thích hoặc đọc trực tiếp thuộc tính POSIX.
Chúng ta sẽ chỉ bật true trong lộ trình C (autorid), và phải đi kèm cờ ldap_idmap_autorid_compat = true để SSSD “bắt chước” đúng thuật toán autorid.
Lộ trình D (tdb) sẽ yêu cầu nâng cấp AD để trở thành giống lộ trình B (ad), nên cũng sẽ dùng ldap_id_mapping = false.

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:

DNS: VPS Linux bắt buộc phải trỏ DNS chính về Domain Controller (DC). Kiểm tra bằng nslookup -type=SRV _kerberos._tcp.yourdomain.com. Nếu gặp lỗi, xem 5 công cụ khắc phục sự cố DNS tốt nhất trên Linux.
NTP: Thời gian trên VPS và DC phải đồng bộ (lệch không quá 5 phút). Cài chrony và trỏ về DC. Kiểm tra bằng chronyc sources.
Kết nối mạng: VPS phải ping được DC. Các cổng cần thiết phải mở (TCP/UDP 53, 88, 389, 464; TCP 3268 nếu dùng Global Catalog). Đảm bảo firewall (như UFW) không chặn các cổng này.

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!

Nếu backend = rid ➔ Đi đến Phần 4 (Lộ trình A).
Nếu backend = ad ➔ Đi đến Phần 5 (Lộ trình B).
Nếu backend = autorid ➔ Đi đến Phần 6 (Lộ trình C).
Nếu backend = tdb ➔ Đi đến Phần 7 (Lộ trình D).

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):

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

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
```
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.
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):

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

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
```
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.
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):

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).

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

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).
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).
Chuyển sang bước hoàn tất:
- Lưu file sssd.conf.
- 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 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:

Cài realmd (Nếu chưa cài).
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

Dừng và vô hiệu hóa Winbind & Samba:

sudo systemctl stop winbind smbd nmbd
sudo systemctl disable winbind smbd nmbd

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).

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

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

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)

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

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.
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 [email protected]
```
So sánh:
- UID và GID trả về từ SSSD phải khớp 100% với UID/GID cũ của Winbind.
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 [email protected]@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ố

Lỗi: id không trả về gì hoặc báo “no such user”:
- Nguyên nhân 1: SSSD chưa chạy hoặc lỗi. Chạy sudo systemctl status sssd và kiểm tra log sudo journalctl -u sssd.
- Nguyên nhân 2: Firewall. Đảm bảo VPS được phép kết nối đến DC qua các cổng cần thiết (Kerberos 88, LDAP 389, DNS 53…).
- Nguyên nhân 3: Lỗi sssd.conf. Kiểm tra lại cấu hình theo đúng lộ trình A/B/C/D.
Lỗi: Đăng nhập thất bại (Clock skew too great):
- Nguyên nhân: Thời gian trên VPS và DC lệch nhau.
- Giải pháp: Đảm bảo chrony đang chạy và đồng bộ. (sudo systemctl restart chrony, chronyc sources).
Lỗi: Bị từ chối đăng nhập (GPO – Access Denied):
- Nguyên nhân: SSSD có thể đang áp dụng GPO (Chính sách Nhóm) chặn đăng nhập.
- Giải pháp: Thêm ad_gpo_access_control = permissive hoặc disabled vào [domain/...] trong sssd.conf và khởi động lại SSSD (sudo systemctl restart sssd).
Lỗi: Không có quyền sudo:
- Giải pháp: Bạn cần cấp lại quyền sudo cho user/group AD. Cách tốt nhất là tạo file /etc/sudoers.d/domain-admins và thêm: %Domain\ Admins ALL=(ALL) ALL (Thay Domain Admins bằng nhóm AD của bạn, dùng dấu \ nếu tên nhóm có khoảng trắng).
Lỗi: UID/GID vẫn bị lệch (Trường hợp xấu nhất):
- Nguyên nhân: Cấu hình sssd.conf sai (ví dụ: nhầm lộ trình, sai range cho autorid, quên --automatic-id-mapping=no…).
- Giải pháp:
  1. sudo systemctl stop sssd.
  2. Kiểm tra lại sssd.conf thật kỹ theo đúng lộ trình.
  3. Xóa trắng cache SSSD: sudo rm -rf /var/lib/sss/db/*.
  4. sudo systemctl start sssd và kiểm tra lại id username.
  5. Nếu vẫn sai, cân nhắc rollback về Winbind (dùng backup) hoặc (cực kỳ rủi ro) chấp nhận UID mới và dùng find ... -exec chown/chgrp ... để đổi chủ sở hữu file.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“Cắt” Winbind

“Ghép” SSSD

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

Kiểm tra ID Mapping

Khắc phục sự cố

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ảnh báo 1: Hiểu đúng về cơ chế ID Mapping của SSSD (`ldap_id_mapping`)

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

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

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

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