Posted inSecurity

Xác thực tập trung trên Linux với FreeIPA: Hướng dẫn thực tế về quản lý người dùng và nhóm

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Tại sao quản lý người dùng thủ công lại thất bại (và tôi đã giải quyết thế nào)

Sau khi server của tôi bị tấn công brute-force SSH lúc nửa đêm, tôi bắt đầu coi xác thực là vấn đề ưu tiên hàng đầu ngay từ ngày đầu của mỗi lần triển khai mới. Nhưng khóa SSH lại chỉ là phần dễ. Vấn đề thực sự nằm ở cấu trúc: mỗi máy Linux có /etc/passwd riêng, người dùng cục bộ riêng, và SSH key nằm rải rác trên laptop của từng thành viên trong nhóm. Khi ai đó nghỉ việc, chúng tôi phải mất hai ba tiếng để truy tìm xem họ có tài khoản trên những server nào — và vẫn lo sợ bỏ sót.

Chính trải nghiệm đó đã thúc đẩy tôi nghiêm túc đánh giá các giải pháp xác thực tập trung. Đây là những gì tôi rút ra sau khi vận hành thực tế.

So sánh các phương án chính

Ở quy mô nhỏ đến vừa, có ba lựa chọn thực sự khả thi:

1. LDAP + PAM (tự xây dựng)

Bạn dựng OpenLDAP rồi kết nối với pam_ldap và nss_ldap. Linh hoạt về lý thuyết, nhưng đau đầu trong thực tế. Việc migration schema, độ trễ replication, và cert TLS hết hạn có cách riêng để ngốn hết cả buổi chiều. Tôi đã chứng kiến các nhóm tốn nhiều công sức hơn để duy trì LDAP server còn hơn là làm sản phẩm thực sự.

2. Active Directory (Samba hoặc Microsoft AD)

Nếu tổ chức của bạn đã dùng Windows AD, việc join máy Linux qua sssd và realmd cũng chạy được. Nhược điểm: bạn bị ràng buộc vào hạ tầng Windows, và AD chưa bao giờ được thiết kế với luồng làm việc thuần Linux trong đầu. Quy tắc Sudo và kiểm soát truy cập theo host đòi hỏi plugin hoặc hack Group Policy — cảm giác như gắn thêm vào cho có.

3. FreeIPA

FreeIPA tích hợp sẵn Kerberos, LDAP (389 Directory Server), DNS, NTP và CA trong một hệ thống thống nhất. Nó được xây dựng cho Linux và Unix ngay từ đầu — không phải chắp vá sau. Giao diện web gọn gàng, quản lý SSH public key được tích hợp sẵn, và bạn có hỗ trợ native cho chính sách sudo và kiểm soát truy cập theo host mà không cần chạm vào một file LDIF nào.

Ưu và nhược điểm của FreeIPA

FreeIPA làm tốt những gì

  • Kerberos SSO tích hợp — Xác thực một lần, nhận ticket cho các dịch vụ. SSH, HTTP qua GSSAPI và nhiều hơn nữa — không cần nhập mật khẩu lặp đi lặp lại.
  • Quy tắc HBAC — Giới hạn người dùng nào được truy cập host nào. Dev junior chỉ vào staging, kỹ sư senior mới vào prod — một chính sách, áp dụng toàn bộ hệ thống.
  • Quy tắc sudo tập trung — Định nghĩa một lần trong FreeIPA. SSSD tự đẩy xuống mọi client. Không còn phải đồng bộ /etc/sudoers trên 20 máy bằng tay nữa.
  • Lưu trữ SSH public key — Lưu key trong FreeIPA, client tự lấy qua SSSD. Thêm hoặc thu hồi key mất chưa đến 10 giây và có hiệu lực ngay trên toàn bộ hệ thống.
  • CA tích hợp — Cấp cert cho dịch vụ và tự động gia hạn. Gọn gàng hơn nhiều so với chạy CA riêng hoặc rải self-signed certificate khắp hạ tầng.
  • Giao diện Web + CLI — Hầu hết các tác vụ hàng ngày (thêm user, reset mật khẩu, thay đổi nhóm) xử lý xong trong vòng một phút trên trình duyệt.

Những điểm cần lưu ý

  • Tài nguyên hệ thống — Lên kế hoạch ít nhất 2 vCPU và 4 GB RAM cho server. VPS 5 đô là không đủ.
  • Phụ thuộc vào DNS — Kerberos rất khắt khe về phân giải tên. DNS bị lỗi đồng nghĩa với xác thực bị lỗi. FreeIPA tự quản lý DNS zone của mình, điều đó giúp ích — nhưng hãy lên kế hoạch phân vùng DNS trước khi chạy installer.
  • Đường cong học tập — Realm, principal, keytab — những khái niệm này khá xa lạ lần đầu tiếp cận. Hãy dành vài tiếng đọc tài liệu trước khi mọi thứ thấm vào đầu.
  • HA cần lên kế hoạch — Một FreeIPA server là một điểm lỗi duy nhất. Hãy chạy ít nhất một replica cho bất kỳ môi trường production nào.

Cấu hình khuyến nghị cho nhóm nhỏ

Với nhóm 5–50 người quản lý 10–100 Linux server, cấu hình này cân bằng tốt giữa sự đơn giản và độ ổn định:

  • 1 FreeIPA primary + 1 replica — cả hai trên mạng nội bộ hoặc VLAN quản lý riêng
  • Tất cả máy production được join làm FreeIPA client qua sssd
  • DNS nội bộ do FreeIPA quản lý (ví dụ: internal.example.com)
  • SSH key lưu trong FreeIPA, tự động lấy về khi đăng nhập — không còn file authorized_keys cần đồng bộ
  • Quy tắc HBAC phân tách quyền truy cập dev, staging và prod

Hướng dẫn triển khai

Bước 1: Cài đặt FreeIPA Server

RHEL 9, Rocky Linux 9 hoặc AlmaLinux 9 là các nền tảng được hỗ trợ tốt nhất. Đặt FQDN đúng chuẩn trước khi làm bất cứ điều gì:

# Đặt hostname
hostnamectl set-hostname ipa.internal.example.com

# Cập nhật /etc/hosts
echo "192.168.1.10 ipa.internal.example.com ipa" >> /etc/hosts

# Cài đặt gói
dnf install -y freeipa-server freeipa-server-dns

# Chạy installer
ipa-server-install \
  --domain=internal.example.com \
  --realm=INTERNAL.EXAMPLE.COM \
  --ds-password=YourDirManagerPass \
  --admin-password=YourAdminPass \
  --setup-dns \
  --auto-forwarders \
  --unattended

Quá trình cài đặt mất khoảng 5–10 phút. Kiểm tra kết quả:

ipactl status

Bước 2: Tạo người dùng và nhóm

Sau khi server chạy, đăng nhập và tạo người dùng đầu tiên. Giao diện web tại https://ipa.internal.example.com hoàn toàn ổn, nhưng CLI nhanh hơn khi cần viết script:

# Xác thực với tài khoản admin
kinit admin

# Tạo người dùng
ipa user-add jdoe \
  --first=John \
  --last=Doe \
  [email protected] \
  --shell=/bin/bash

# Đặt mật khẩu ban đầu
ipa passwd jdoe

# Tạo nhóm
ipa group-add devops --desc="Kỹ sư DevOps"

# Thêm người dùng vào nhóm
ipa group-add-member devops --users=jdoe

Bước 3: Lưu SSH key vào FreeIPA

Đây là tính năng khiến các sysadmin ngạc nhiên nhất khi thấy lần đầu. Upload key một lần — dùng được ở khắp nơi:

# Upload SSH public key cho người dùng
ipa user-mod jdoe --sshpubkey="$(cat /home/jdoe/.ssh/id_ed25519.pub)"

SSSD trên các máy client tự động lấy key khi đăng nhập. Không cần đồng bộ file, không cần cron job, không lo lệch nhau.

Bước 4: Join máy Linux client vào FreeIPA

Chạy lệnh này trên từng server bạn muốn đưa vào quản lý tập trung:

# Cài đặt công cụ client
dnf install -y freeipa-client

# Join vào domain
ipa-client-install \
  --domain=internal.example.com \
  --server=ipa.internal.example.com \
  --realm=INTERNAL.EXAMPLE.COM \
  --principal=admin \
  --password=YourAdminPass \
  --mkhomedir \
  --unattended

Sau khi đăng ký xong, mọi người dùng FreeIPA đều có thể SSH vào máy bằng thông tin xác thực tập trung — không cần tài khoản cục bộ.

Bước 5: Cấu hình quy tắc HBAC

Sau khi cài đặt mới, mọi người dùng FreeIPA đều được phép truy cập tất cả host đã đăng ký. Hãy tắt điều đó ngay lập tức:

# Vô hiệu hóa quy tắc mặc định cho phép tất cả
ipa hbacrule-disable allow_all

# Tạo quy tắc: nhóm devops được truy cập server prod
ipa hbacrule-add allow_devops_prod \
  --desc="Quyền truy cập của DevOps vào các host production"

ipa hbacrule-add-user allow_devops_prod --groups=devops
ipa hbacrule-add-host allow_devops_prod --hosts=prod-web-01.internal.example.com
ipa hbacrule-add-service allow_devops_prod --hbacsvcs=sshd

# Mô phỏng kiểm tra quyền truy cập trước khi áp dụng
ipa hbactest \
  --user=jdoe \
  --host=prod-web-01.internal.example.com \
  --service=sshd

Bước 6: Tập trung hóa quy tắc Sudo

Không còn phải phân phối file sudoers bằng tay nữa. Định nghĩa quy tắc một lần, để SSSD lo việc truyền tải:

# Tạo quy tắc sudo cho devops
ipa sudorule-add devops_all_commands \
  --desc="DevOps được chạy mọi lệnh với quyền root"

ipa sudorule-add-user devops_all_commands --groups=devops
ipa sudorule-add-host devops_all_commands --hostgroups=ipaservers
ipa sudorule-mod devops_all_commands --cmdcat=all
ipa sudorule-mod devops_all_commands --runasusercat=all

SSSD sẽ cập nhật quy tắc này vào lần làm mới cache tiếp theo — thường dưới 60 giây. Không cần visudo, không cần SSH vào 20 máy.

Bước 7: Thiết lập Replica

Một FreeIPA server duy nhất không nên là server xác thực duy nhất trong môi trường production. Trên máy thứ hai, việc cài replica khá đơn giản:

# Cài đặt gói FreeIPA server
dnf install -y freeipa-server

# Join với vai trò replica
ipa-replica-install \
  --setup-ca \
  --setup-dns \
  --principal=admin \
  --admin-password=YourAdminPass

Replication mặc định là đồng bộ và thường ổn định trong vòng chưa đến một giây. Nếu primary bị sập, SSSD trên client tự động chuyển sang replica — không cần can thiệp thủ công.

Bài học từ thực tế vận hành FreeIPA

  • Luôn kiểm tra quy tắc HBAC bằng ipa hbactest trước. Tôi đã từng tự khóa mình ra khỏi server vì tắt allow_all trước khi quy tắc thay thế được thiết lập xong. Lệnh mô phỏng tồn tại chính xác vì lý do đó — hãy dùng nó.
  • Theo dõi thời hạn ticket Kerberos. Mặc định là 24 giờ. Các tác vụ chạy lâu dài phụ thuộc vào Kerberos sẽ bị lỗi khi ticket hết hạn. Dùng k5start hoặc keytab cho các tài khoản dịch vụ.
  • Không bỏ qua kiểm tra DNS. Chạy ipa dns-check và sửa mọi cảnh báo trước khi join client. Lỗi DNS sinh ra các thông báo lỗi Kerberos rất khó hiểu, cực kỳ khổ sở khi debug dưới áp lực.
  • Điều chỉnh offline cache của SSSD. Nếu FreeIPA server tạm thời không thể truy cập, SSSD dùng thông tin xác thực đã cache — nhưng chúng có hạn. Đặt cache_credentials = True và krb5_store_password_if_offline = True trong /etc/sssd/sssd.conf cho các máy có thể mất kết nối.
  • Offboarding trở nên cực kỳ đơn giản. Một lệnh duy nhất vô hiệu hóa quyền truy cập của người dùng trên mọi máy đã đăng ký ngay lập tức: ipa user-disable jdoe. Chính khả năng này thường đủ để biện minh cho toàn bộ công sức triển khai FreeIPA.
Share:
Tags: