SSSD vs Winbind: Giải pháp nào là tốt nhất để join VPS Linux vào Active Directory?

Trong bất kỳ môi trường doanh nghiệp nào, việc quản lý một hệ thống “lai” (hybrid) luôn đặt ra bài toán tích hợp VPS Linux vào Active Directory (AD). Khi đó, câu hỏi kỹ thuật lớn nhất mà mọi quản trị viên hệ thống phải đối mặt chính là: nên chọn SSSD vs Winbind? Đây không chỉ là về sự tiện lợi, mà còn là về bảo mật tập trung, tuân thủ chính sách và kiểm soát truy cập, cho phép nhân viên IT dùng chính tài khoản AD để đăng nhập SSH vào máy chủ Ubuntu hay sudo trên máy chủ CentOS.

Đây chính là lúc nhu cầu tích hợp VPS Linux vào Active Directory trở nên sống còn. Nó không chỉ là về sự tiện lợi, mà còn là về bảo mật tập trung, tuân thủ chính sách (compliance) và kiểm soát truy cập (audit).

Nhưng khi bắt tay vào tìm giải pháp, bạn sẽ ngay lập tức đứng giữa một ngã ba đường, một “cuộc chiến” kinh điển trong giới quản trị hệ thống Linux:

1. Winbind (Samba): Giải pháp “cổ điển”, đã tồn tại hàng thập kỷ. Nó mạnh mẽ, tích hợp sâu với hệ sinh thái Windows, nhưng nổi tiếng là phức tạp và yêu cầu cấu hình thủ công tỉ mỉ.
2. SSSD (realmd): Giải pháp “hiện đại”, được thiết kế lại từ đầu. Nó nhanh, an toàn, tự động hóa cao và là lựa chọn mặc định trên nhiều bản phân phối lớn hiện nay.

Bài viết này không phải là một hướng dẫn cài đặt đơn thuần. Đây là một bài phân tích chuyên sâu về kiến trúc, bảo mật, hiệu suất và các kịch bản sử dụng thực tế của SSSD và Winbind. Mục tiêu của chúng tôi là trang bị cho bạn đủ kiến thức để đưa ra quyết định “chọn cái nào” một cách tự tin, tránh được những sai lầm tốn thời gian và rủi ro kỹ thuật.

Nếu bạn đã có quyết định và chỉ muốn bắt tay vào thực hành ngay, chúng tôi đã chuẩn bị sẵn hai hướng dẫn chi tiết:

• [Cách 1 – Hiện đại & khuyến nghị] 7 bước join VPS Linux vào AD bằng realmd (SSSD)
• [Cách 2 – Cổ điển & nhu cầu đặc thù] Cách join VPS Linux vào AD (Sử dụng Samba/Winbind)

Tóm tắt nhanh (TL;DR): Bảng so sánh SSSD vs Winbind

Đối với những người bận rộn cần một câu trả lời ngay lập tức, đây là bảng so sánh kỹ thuật chi tiết nhất giữa hai giải pháp:

Tính năng	SSSD (System Security Services Daemon)	Winbind (Một phần của Samba)
Mục đích cốt lõi	Quản lý danh tính & xác thực (Identity Management)	Chia sẻ tệp/in (Samba) & xác thực
Công cụ cài đặt	realmd (Tự động hóa cao)	Cấu hình thủ công (Manual)
Công nghệ nền	Daemon độc lập, kiến trúc module (Responders/Providers)	Một phần của Samba suite (phụ thuộc smbd, nmbd)
Giao thức chính	Kerberos, LDAP/S (Ưu tiên hiện đại, an toàn)	MS-RPC, Kerberos (Có thể fallback NTLM)
Bảo mật	Rất cao (Kerberos-first). Tránh NTLM (cũ, kém an toàn).	Trung bình. Hỗ trợ NTLM cho tương thích ngược (legacy).
Caching (Đăng nhập Offline)	Rất mạnh. Đây là tính năng cốt lõi.	Hạn chế hoặc không có. Rất phụ thuộc vào kết nối DC.
Hiệu suất	Cao. Giảm tải DC, cache nhanh, daemon nhẹ.	Trung bình. “Nặng” hơn do là một phần của Samba.
Cấu hình	Đơn giản. realm join tự cấu hình mọi thứ.	Rất phức tạp. Phải sửa 5+ file (smb.conf, krb5.conf, nss, pam…)
Ánh xạ ID (ID Map)	Tự động, linh hoạt, nhất quán.Hạn chế. Chủ yếu là kiểm soát truy cập (vd: ad_gpo_access_control). Cần công cụ riêng (như ADSys trên Ubuntu) để áp dụng chính sách GPO đầy đủ.	Phức tạp (cần cấu hình idmap backend: autorid, rid, tdb)
Hỗ trợ GPOs	Hạn chế. Chủ yếu là kiểm soát truy cập (vd: ad_gpo_access_control). Cần công cụ riêng (như ADSys trên Ubuntu) để áp dụng chính sách GPO đầy đủ.	Tích hợp sâu hơn. Là một phần của Samba, được thiết kế để “bắt chước” Windows client, do đó hỗ trợ nhiều chính sách GPO hơn (nhưng cấu hình phức tạp).
Use Case tốt nhất	90% VPS (Web, App, DB), Laptop di động, Môi trường bảo mật cao.	10% VPS (Làm File Server, cần GPO, legacy NTLM)

Dành cho ai? Quyết định nhanh trong 60 giây

Dựa trên bảng so sánh trên, đây là lời khuyên nhanh để bạn quyết định:

Bạn nên chọn SSSD (và dùng realmd) nếu:

• Bạn cần join VPS (Web server, Application server, Database server) vào AD để xác thực SSH và cấp quyền sudo.
• Bạn ưu tiên bảo mật, sự đơn giản và tự động hóa trong triển khai.
• Bạn cần tính năng đăng nhập offline (cho laptop của nhân viên hoặc VPS có kết nối mạng không ổn định đến DC).
• Bạn đang dùng các bản phân phối Linux hiện đại (CentOS 8+, Ubuntu 20.04+, RHEL 8+).
• Bạn muốn một giải pháp “cài đặt và quên đi” (set-it-and-forget-it) mà không cần bảo trì phức tạp.

Đã quyết định? Đây là giải pháp dành cho bạn. Xem ngay hướng dẫn chi tiết: Hướng dẫn 7 bước join VPS Linux vào AD bằng realmd (SSSD)

Bạn chỉ nên chọn Winbind (Samba) nếu:

• Vai trò chính của VPS là làm Samba File Server và cần tích hợp quyền (ACLs) sâu với người dùng AD.
• Bạn có yêu cầu bắt buộc phải áp dụng Group Policy Objects (GPOs) từ AD xuống máy chủ Linux.
• Bạn đang ở trong môi trường rất cũ (legacy), cần hỗ trợ fallback (dự phòng) cho NTLM (ví dụ: cho Squid proxy).
• Bạn là quản trị viên hệ thống “lão làng”, muốn kiểm soát thủ công 100% mọi file cấu hình và hiểu rõ mình đang làm gì.

Đây là trường hợp của bạn? Phương pháp này phức tạp nhưng cho phép kiểm soát tối đa. Tham khảo Hướng dẫn cấu hình thủ công với Samba/Winbind

Phân tích kiến trúc chuyên sâu: SSSD hoạt động như thế nào?

Để hiểu tại sao SSSD vượt trội, chúng ta cần nhìn vào kiến trúc bên trong nó.

SSSD không chỉ là một công cụ “Join Domain”. Nó là một bộ khung (framework) quản lý danh tính hoàn chỉnh. Nó được thiết kế thông minh, chia làm 3 phần:

1. “Bộ não” (sssd): Là tiến trình chính, quản lý cache và điều phối.
2. “Đầu” giao tiếp với Linux: Một phần chuyên cung cấp thông tin user/group cho hệ thống (để chạy lệnh id), một phần chuyên xử lý xác thực (để đăng nhập SSH, sudo).
3. “Đuôi” giao tiếp với AD: Một phần chuyên xác thực mật khẩu (qua Kerberos), một phần chuyên lấy thông tin danh tính (qua LDAP).

“Phép màu” của Caching

Điểm “ăn tiền” nhất của SSSD là cơ chế caching thông minh. Thay vì mỗi lần chạy lệnh id đều phải hỏi Domain Controller (DC), SSSD hoạt động như sau:

1. Lần đầu tiên bạn truy vấn id user@ad, SSSD-NSS yêu cầu SSSD-Core.
2. SSSD-Core yêu cầu Identity Provider (AD) cung cấp thông tin cho user@ad.
3. SSSD lưu thông tin này (UID, GID, các nhóm) vào một database cache cục bộ (thường là /var/lib/sss/db/cache_YOURDOMAIN.COM.ldb).
4. SSSD trả kết quả cho SSSD-NSS, và SSSD-NSS trả về cho bạn.
5. Lần thứ hai bạn chạy id user@ad (chỉ 1 giây sau), SSSD-NSS chỉ cần hỏi thẳng cache cục bộ mà không cần liên hệ DC.

Điều này mang lại hai lợi ích khổng lồ:

1. Hiệu suất: Tốc độ phản hồi gần như tức thời.
2. Đăng nhập Offline: Khi bạn đăng nhập SSH, SSSD-PAM sẽ kiểm tra mật khẩu với Authentication Provider (Kerberos). Nếu thành công, nó sẽ lưu một bản hash an toàn của thông tin đăng nhập vào cache. Nếu VPS bị mất mạng, SSSD-PAM sẽ kiểm tra mật khẩu bạn gõ với bản hash trong cache. Nếu khớp, bạn vẫn đăng nhập được.

• Xem thêm: Cấu hình Squid Kerberos Active Directory: Cấu hình SSO loại bỏ pop-up xác thực • ZingServer

Vai trò thực sự của realmd

Rất nhiều người nhầm lẫn realmd với SSSD. realmd không phải là SSSD.

realmd là một dịch vụ “điều phối” cấp cao. Nó là một công cụ “phát hiện” (discovery) thông minh. Khi bạn chạy realm discover YOURDOMAIN.COM, nó sẽ:

1. Dùng DNS (truy vấn SRV records như _kerberos._tcp) để tìm Domain Controller.
2. Xác định đây là loại domain gì (Active Directory, FreeIPA, hay LDAP).
3. Biết cần phải cài đặt và cấu hình phần mềm nào (ví dụ: sssd, krb5-workstation).

• Xem thêm: Cách định cấu hình DNS trong Ubuntu/Debian, CentOS/Fedora • ZingServer

Khi bạn chạy realm join YOURDOMAIN.COM, realmd sẽ tự động:

• Cài các gói cần thiết.
• Tạo file /etc/krb5.conf chuẩn.
• Tạo file /etc/sssd/sssd.conf với các cấu hình tối ưu cho AD.
• Cấu hình nsswitch.conf và PAM để hệ thống “nói chuyện” với SSSD.
• Join máy vào domain (tạo computer account).
• Khởi động dịch vụ sssd.

Nói cách khác, realmd làm thay bạn toàn bộ công việc cấu hình thủ công nhàm chán mà Winbind yêu cầu, như đã thấy trong bài hướng dẫn join bằng realmd.

Phân tích kiến trúc chuyên sâu: Winbind hoạt động như thế nào?

Winbind có một lịch sử lâu đời và kiến trúc của nó phản ánh điều đó. Winbind là một phần không thể tách rời của bộ công cụ Samba.

Mục đích ban đầu của Samba là cho phép máy Linux hoạt động như một máy chủ file (File Server) cho các máy khách Windows. Để làm điều này, nó cần “hiểu” người dùng và nhóm của Windows. Dịch vụ winbindd ra đời để giải quyết bài toán đó: nó làm cầu nối giữa hệ thống xác thực của Linux (NSS, PAM) và hệ thống của Windows (AD).

Kiến trúc “cổ điển”

• Giao tiếp qua MS-RPC: Không giống SSSD ưu tiên LDAP/Kerberos, Winbind “giả lập” thành một Windows Client hoàn chỉnh. Nó nói chuyện với Domain Controller chủ yếu qua giao thức MS-RPC (Microsoft Remote Procedure Call) – chính là giao thức mà các máy Windows dùng để nói chuyện với nhau.
• Sự phụ thuộc: Winbind cần các dịch vụ khác của Samba (smbd, nmbd) để hoạt động chính xác trong việc khám phá domain và các dịch vụ. Điều này khiến nó “nặng nề” hơn SSSD (vốn là một daemon độc lập).

Nỗi đau của ID Mapping (idmap)

Đây là phần phức tạp và dễ gây lỗi nhất của Winbind mà SSSD đã giải quyết một cách thanh lịch.

• Vấn đề: Active Directory quản lý mọi thứ bằng SID (Security Identifiers – ví dụ: S-1-5-21-.....-1103). Linux quản lý mọi thứ bằng UID (User ID) và GID (Group ID) (ví dụ: 1001).
• Giải pháp: Winbind cần một cơ chế gọi là idmap backend để dịch qua lại giữa SID ↔ UID/GID.
• Sự phức tạp: Bạn phải tự tay chọn và cấu hình một backend trong file smb.conf. Như bạn thấy trong bài hướng dẫn Winbind của chúng tôi, chúng ta đã dùng autorid. Nhưng ngoài ra còn có:
  • idmap_rid: Tính toán UID/GID dựa trên phần RID (Relative ID) của SID. Cách này phổ biến nhưng dễ xung đột nếu dải RID quá lớn.
  • idmap_ad: Sử dụng các thuộc tính uidNumber và gidNumber trong AD (yêu cầu phải mở rộng schema của AD).
  • idmap_tdb: Lưu trữ bản đồ ánh xạ trong một file database (.tdb) cục bộ. Cách này cũ và không nhất quán giữa các máy chủ.

Sự phức tạp của idmap là nguồn gốc của vô số giờ gỡ lỗi: tại sao user A trên server 1 có UID 15000 nhưng trên server 2 lại có UID 16010? SSSD giải quyết việc này bằng cách tự động xử lý ánh xạ một cách nhất quán.

Quy trình thủ công

Chính vì kiến trúc này, việc cấu hình Winbind là một quy trình thủ công 100%. Bạn phải:

1. Chỉnh sửa krb5.conf (để Kerberos biết tìm DC). Bước này đều yêu cầu đồng bộ thời gian (NTP) tuyệt đối chính xác giữa VPS Linux và Domain Controller.
2. Chỉnh sửa smb.conf (quan trọng nhất: để cấu hình workgroup, realm, security = ads, và idmap backend).
3. Chỉnh sửa nsswitch.conf (để Linux “thấy” user từ winbind).
4. Chỉnh sửa PAM (để cho phép winbind xác thực đăng nhập).

Mỗi bước đều có thể sai sót, và cấu hình khác nhau một chút giữa RHEL/CentOS và Ubuntu/Debian, như đã thấy trong hướng dẫn chi tiết của chúng tôi.

So sánh trực diện các kịch bản (Use Case) thực tế

Lý thuyết là vậy, nhưng khi nào nên dùng cái nào trong thực tế?

Kịch bản 1: Cụm 100 VPS Web/App Server (High Performance)

• Nhu cầu: Cần join 100 VPS (chạy Nginx, PHP, Node.js…) vào AD để dev team có thể SSH vào bằng tài khoản AD. Ưu tiên tốc độ, tự động hóa và hiệu suất.
• Người chiến thắng: SSSD.
• Lý do:
  1. Tự động hóa: Bạn có thể dùng Ansible, Terraform hoặc Cloud-Init để chạy một lệnh realm join duy nhất. Không cần các template smb.conf phức tạp.
  2. Hiệu suất: Caching của SSSD là cứu cánh. Nó giảm hàng nghìn truy vấn không cần thiết (mỗi lần SSH, mỗi lần chạy sudo) đến Domain Controller.
  3. Tài nguyên: SSSD là daemon nhẹ, không mang theo “hành lý” là toàn bộ bộ Samba. Tài nguyên VPS được tập trung cho ứng dụng.

• Xem thêm: VPS Linux CPU 100%: Hướng dẫn chẩn đoán và xử lý triệt để nguyên nhân gốc rễ • ZingServer

Kịch bản 2: VPS làm File Server nội bộ (Chia sẻ file cho Windows)

• Nhu cầu: Một VPS Linux (dùng XFS/Ext4) được dùng làm ổ đĩa mạng (network drive) cho 50 nhân viên Windows. Cần quản lý quyền đọc/ghi file (ACLs) bằng tài khoản AD.
• Người chiến thắng: Winbind.
• Lý do: Đây chính là mục đích Winbind được sinh ra. Nó tích hợp nguyên bản với dịch vụ smbd (Samba daemon). Khi một user Windows truy cập file share, smbd sẽ hỏi winbindd xem SID này là ai, có quyền gì, và áp dụng ACLs trên hệ thống file Linux một cách hoàn hảo.

Kịch bản 3: Laptop của lập trình viên (Thường xuyên Offline)

• Nhu cầu: Công ty cấp laptop chạy Ubuntu cho lập trình viên. Máy đã join domain. Lập trình viên cần mang máy về nhà (không có kết nối VPN/mạng công ty) và vẫn đăng nhập được để làm việc.
• Người chiến thắng: SSSD.
• Lý do: Caching Offline. Đây là tính năng mà Winbind không thể làm tốt bằng. SSSD cho phép lập trình viên đăng nhập bằng mật khẩu đã được cache an toàn. Khi có mạng trở lại, SSSD tự động đồng bộ. Winbind sẽ thất bại ngay khi không thể liên lạc với DC.

Kịch bản 4: Môi trường bảo mật cao (Compliance, PCI/DSS)

• Nhu cầu: Hệ thống VPS Linux chứa dữ liệu nhạy cảm, cần tuân thủ các tiêu chuẩn bảo mật nghiêm ngặt. Cấm tuyệt đối các giao thức cũ, mọi thứ phải được mã hóa và kiểm toán (audit).
• Người chiến thắng: SSSD.
• Lý do:
  1. Kerberos-first: SSSD ưu tiên Kerberos, không gửi hash mật khẩu qua mạng.
  2. Không NTLM: SSSD không (hoặc rất khó) để cấu hình fallback về NTLM, một giao thức cũ và không an toàn. Winbind, vì lý do tương thích ngược, có thể bị cấu hình để cho phép NTLM.
  3. Kiểm toán: Kiến trúc SSSD rõ ràng, dễ kiểm toán log hơn.

• Xem thêm: Bảo mật VPS Linux với UFW, Fail2Ban và Hardening SSH • ZingServer

Kịch bản 5: Môi trường “lai” (Cần cả xác thực VÀ File Server)

• Nhu cầu: Một VPS Linux vừa cần cho phép admin SSH vào bằng tài khoản AD, vừa phải share một thư mục /data cho user Windows.
• Trường hợp phức tạp: Đây là lúc cần cân nhắc.
  • Lựa chọn 1 (Đơn giản): Dùng Winbind cho tất cả. Chấp nhận việc xác thực SSH/sudo kém hiệu quả hơn một chút (không cache offline) để đổi lấy sự đơn giản trong cấu hình (chỉ cần 1 hệ thống).
  • Lựa chọn 2 (Nâng cao & hiện đại): Dùng SSSD cho xác thực (SSH, sudo) VÀ cài đặt Samba (chỉ để share file). Sau đó, cấu hình Samba sử dụng sssd-cifs-idmap để lấy thông tin user từ SSSD. Đây là kiến trúc được Red Hat khuyến nghị, nó cho bạn lợi ích của cả hai thế giới (SSSD caching + Samba sharing) nhưng đòi hỏi chuyên môn cấu hình cao hơn.

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

1. Tóm lại, tôi nên dùng SSSD hay Winbind cho VPS Linux?

Hãy chọn SSSD cho 90% trường hợp. Nếu VPS của bạn là máy chủ Web, Ứng dụng, hoặc Database và bạn chỉ cần xác thực SSH/sudo, SSSD (với realmd) là lựa chọn hiện đại, an toàn, hiệu suất cao và hỗ trợ đăng nhập offline.

Bạn chỉ nên chọn Winbind nếu VPS của bạn có vai trò chính là Samba File Server và cần tích hợp sâu quyền ACLs của Windows.

2. Tại sao SSSD (với realmd) được coi là “hiện đại” hơn?

Vì 3 lý do chính:

1. Hiệu suất & Caching: SSSD cache thông tin đăng nhập và danh tính rất thông minh, cho phép đăng nhập offline và giảm tải cực lớn cho Domain Controller.
2. Bảo mật: SSSD ưu tiên các giao thức hiện đại (Kerberos-first) và tránh các giao thức legacy kém an toàn như NTLM.
3. Tự động hóa: Công cụ realmd tự động hóa 100% quá trình cấu hình (tự viết file sssd.conf, krb5.conf, PAM…). Bạn chỉ cần một lệnh realm join thay vì sửa 5+ file thủ công như Winbind.

3. Realmd là gì? Nó có phải là SSSD không?

Không. Đây là 2 thứ khác nhau nhưng làm việc cùng nhau:

• SSSD là dịch vụ (daemon) chạy nền, chịu trách nhiệm liên tục giao tiếp với AD, cache dữ liệu và xử lý xác thực.
• Realmd là công cụ “cài đặt” chạy một lần. Nó tự động phát hiện AD, sau đó tự động viết file cấu hình cho SSSD, Kerberos, và PAM.

Nói đơn giản: Bạn dùng realmd một lần để join, nhưng sssd mới là thứ chạy mãi mãi để duy trì kết nối.

4. SSSD có hỗ trợ Group Policy (GPO) không?

Hỗ trợ hạn chế. SSSD (với tùy chọn ad_gpo_access_control) chủ yếu dùng GPO để kiểm soát truy cập (ai được phép/bị cấm đăng nhập SSH).

Nó không phải là một GPO client toàn năng (như chạy script, ép cấu hình desktop). Để làm điều đó trên Linux hiện đại, bạn cần các công cụ riêng biệt chạy song song với SSSD, ví dụ như ADSys của Canonical cho Ubuntu. Winbind (Samba) có lịch sử hỗ trợ GPO sâu hơn vì nó cố gắng “bắt chước” một Windows client hoàn chỉnh.

5. Tôi đang dùng Winbind, chuyển sang SSSD có khó không?

Có thể thực hiện được, nhưng phức tạp. Thách thức kỹ thuật lớn nhất và rủi ro nhất chính là UID/GID Mapping. Bạn phải đảm bảo SSSD ánh xạ ID người dùng/nhóm khớp chính xác với cách Winbind đã làm. Nếu ánh xạ sai, người dùng sẽ bị mất quyền sở hữu (permission) đối với tất cả các file của chính họ.

Kết luận

Cuộc chiến “SSSD vs Winbind” đã đi đến hồi kết. Mặc dù Winbind là một công cụ mạnh mẽ, đáng kính đã phục vụ cộng đồng Linux trong nhiều thập kỷ, nhưng SSSD rõ ràng là tiêu chuẩn của hiện tại và tương lai cho hầu hết các kịch bản tích hợp VPS Linux.

• SSSD là tiêu chuẩn hiện đại. Nó nhanh hơn, an toàn hơn, ổn định hơn và giải quyết các vấn đề cốt lõi (caching, offline, tự động hóa) mà Winbind bỏ ngỏ. Kiến trúc module của nó cũng linh hoạt hơn cho tương lai.
• Winbind vẫn có vị trí của nó. Nó không “chết”, mà trở thành một “công cụ chuyên dụng”. Nó là lựa chọn đúng đắn và duy nhất nếu vai trò chính của VPS là làm File Server tích hợp sâu với Samba ACLs.

Lời khuyên cuối cùng: Hãy bắt đầu với SSSD. Nó giải quyết 90% nhu cầu tích hợp VPS của bạn. Chỉ sử dụng Winbind nếu bạn biết chắc mình thuộc 10% các trường hợp đặc biệt (chủ yếu là Samba File Server).

Giờ bạn đã có đầy đủ thông tin để đưa ra quyết định mang tính kiến trúc cho hệ thống của mình. Hãy chọn hướng dẫn phù hợp với lựa chọn của bạn:

• Lựa chọn 1: Hiện đại, Tự động & Khuyến nghị (SSSD) Bạn đã sẵn sàng trải nghiệm sự đơn giản và sức mạnh của SSSD?
  • Click để xem -> 7 bước join VPS Linux vào AD bằng realmd (Ubuntu/CentOS)
• Lựa chọn 2: Cổ điển, Thủ công & Nhu cầu đặc thù (Winbind) Bạn cần tích hợp Samba File Server hoặc muốn kiểm soát thủ công toàn bộ quá trình?
  • Click để xem -> Cách join VPS Linux vào AD (Sử dụng Samba/Winbind)

Tài liệu tham khảo

• Integrating RHEL systems directly with Windows Active Directory | Red Hat Enterprise Linux | 9 | Red Hat Documentation
• How to set up SSSD with Active Directory – Ubuntu Server documentation
• SSSD – System Security Services Daemon – sssd.io
• Setting up Samba as a Domain Member – SambaWiki