4.2. Users and Groups: sudo, truy cập root và xác thực tập trung
Mục lục
- 1. Vì sao mọi thao tác quản trị đều đi qua sudo?
- 2. Cấp quyền sudo qua group sudo
- 3. Năm trường của một dòng policy trong file sudoers
- 4. Các mẫu policy thường dùng trong sudoers
- 5. Truy cập account root
- 6. Quản lý user trên hàng trăm server và vai trò của LDAP
- 7. Dựng LDAP server thử nghiệm bằng LXC
- 8. Cấu hình client để lấy user và group từ LDAP
1. Vì sao mọi thao tác quản trị đều đi qua sudo?
Mọi lần cần thay đổi một thứ quan trọng trên hệ thống, lệnh đều có sudo đứng trước. Lý do nằm ở chỗ chỉ user root, cũng gọi là superuser, mới sửa được những vùng quan trọng của operating system. Khi đặt sudo trước một lệnh, lệnh đó chạy như thể chính root thực thi nó.
Câu hỏi tiếp theo là vì sao một user thường lại được phép dùng sudo. Chạy lệnh sau sẽ thấy câu trả lời:
groups
# Output (minh họa):
aaron : aaron adm cdrom sudo dip plugdev
User này thuộc group sudo. Bất cứ ai là thành viên của group đó đều tự động được dùng sudo.
2. Cấp quyền sudo qua group sudo
Từ nhận xét trên, cách đơn giản nhất để cấp quyền sudo cho một user khác là thêm họ vào group sudo. Thêm user trinity vào group đó:
sudo gpasswd --add trinity sudo
Xong. Từ giờ trinity lấy được quyền administrator bất cứ lúc nào cô ta muốn.
Nhưng cách này trao cho họ sức mạnh làm mọi thứ trên hệ thống, không chừa ngoại lệ nào. Khi cần kiểm soát mịn hơn, có một hướng khác: một file đặc biệt nằm trong folder /etc, đọc từng chữ là S-U-D-O-E-R-S, tức /etc/sudoers. File này định nghĩa ai được dùng sudo, trong điều kiện nào, chạy được những lệnh nào.
File đó không nên sửa trực tiếp. Công cụ dành cho việc sửa nó là visudo, cái tên ghép từ vi và sudo. Tiện ích này kiểm tra xem nội dung vừa sửa có đúng cú pháp hay không trước khi lưu, nhờ vậy tránh được những lỗi làm cả file sudoers mất hiệu lực.
Trước khi định nghĩa policy riêng cho trinity, bỏ cô ta ra khỏi group sudo để bảo đảm quyền hiện tại của cô ta không còn:
sudo gpasswd --delete trinity sudo
Rồi mở file sudoers ra sửa:
sudo visudo
File mở ra trong editor Vim.
💡 Hình dung:
visudogiống một cánh cửa có người soát vé: vẫn là sửa đúng file đó, nhưng không cho mang ra ngoài một bản nội dung sai cú pháp. Sửa thẳng/etc/sudoersbằng editor thường là đi cửa sau, và một dấu ngoặc thiếu đủ để khóa cả hệ thống khỏi quyền quản trị.
3. Năm trường của một dòng policy trong file sudoers
File sudoers có rất nhiều dòng comment. Phần đầu file chưa cần tới, nên đi thẳng xuống cuối. Ở đó có một dòng cho phép mọi người trong group sudo chạy mọi lệnh:
%sudo ALL=(ALL:ALL) ALL
Dòng này là lý do mọi user được thêm vào group sudo đều chạy được bất cứ lệnh nào với sudo. Tách nó ra thành năm phần sẽ thấy từng phần làm gì.
Từng trường một:
- User hoặc group. Nơi khai policy này dành cho ai. Dấu
%ở đầu đánh dấu đây là tên group thay vì tên user. - Host. Nơi khai rằng các quy tắc này chỉ áp dụng khi hostname hay IP address của server mang một giá trị cụ thể. Phần này ít dùng tới trong thực tế, nên hầu như luôn điền
ALL. - Run as user. Nơi liệt kê các username. Bình thường,
sudo lschạy lệnhlsvới tư cách root, vì đó là việcsudolàm: chạy lệnh dưới một user khác, và mặc định user đó là root. Nhưngsudocũng dùng được đểaaronchạy lệnh thay cho một user thường khác nhưjane. Nếu trường này liệt kêaaron, janethìsudochỉ chạy lệnh được dưới user aaron hoặc jane, không chạy được dưới root. Muốn khai nhiều giá trị thì liệt kê lần lượt, phân cách bằng dấu phẩy. - Run as group. Hoạt động như trường trên nhưng cho group. Điền
ALLthì user thuộc groupsudodùngsudođể chạy lệnh dưới bất cứ group nào. Điền một tên group cụ thể thì họ chỉ chạy lệnh được dưới group đó. - Danh sách lệnh. Những lệnh được phép thực thi qua
sudo.
Ghép lại, cú pháp của một policy trong file sudoers có dạng:
user host=(runas_user:runas_group) commands
4. Các mẫu policy thường dùng trong sudoers
Định nghĩa policy cho user trinity, cho cô ta chạy mọi lệnh qua sudo:
trinity ALL=(ALL) ALL
Phần trong ngoặc đơn chỉ khai một giá trị ALL, nghĩa là trinity chạy được lệnh dưới mọi user. Phần group không được khai, nhưng ngầm hiểu rằng cô ta cũng chạy được lệnh dưới mọi group, dù trường ALL thứ hai không có mặt.
Khai policy cho mọi user trong group developers thì thêm dấu % trước tên group, và dòng đó bao trùm toàn bộ thành viên của group:
%developers ALL=(ALL:ALL) ALL
Chạy lệnh dưới một user thường
Phần trên có nói sudo chạy lệnh được dưới root và cũng dưới user thường. Để chạy lệnh ls /home/trinity với tư cách user trinity:
sudo -u trinity ls /home/trinity
Sau -u là username muốn chạy lệnh dưới danh nghĩa người đó. Khi trường thứ ba của policy là ALL thì policy đó cho phép chạy lệnh sudo dưới bất cứ user nào. Muốn trinity chỉ chạy được lệnh sudo dưới user aaron hoặc jane:
trinity ALL=(aaron,jane) ALL
Trường thứ ba được bọc trong ngoặc đơn, và cặp ngoặc đó gợi ý rằng trường này không bắt buộc. Nên dòng dưới đây cũng hợp lệ:
trinity ALL=ALL
Giới hạn danh sách lệnh
Với các dòng ở trên, user hay group được cấp quyền sudo chạy được bất cứ lệnh nào. Giới hạn lại thành đúng hai lệnh:
trinity ALL=(ALL:ALL) /usr/bin/ls, /usr/bin/stat
Trinity chạy được ls hoặc stat, và chỉ hai lệnh đó hoạt động. Thử một lệnh khác, cô ta nhận thông báo từ chối:
sudo cat /etc/shadow
# Output (minh họa):
Sorry, user trinity is not allowed to execute '/usr/bin/cat /etc/shadow' as root on server01.
Vì trường thứ ba không bắt buộc, dòng trên viết gọn lại được thành:
trinity ALL=/usr/bin/ls, /usr/bin/stat
Bỏ bước hỏi password
Lần đầu chạy một lệnh sudo trong một session, hệ thống hỏi password của chính user hiện tại. Trong file sudoers có gợi ý nằm ngay trong phần comment về cách bỏ yêu cầu đó. Áp dụng cho trinity thì viết dòng này vào file sudoers:
trinity ALL=(ALL:ALL) NOPASSWD: ALL
| Dòng policy | Ý nghĩa |
|---|---|
%sudo ALL=(ALL:ALL) ALL | Mọi thành viên group sudo chạy mọi lệnh dưới mọi user và mọi group |
trinity ALL=(ALL) ALL | Trinity chạy mọi lệnh dưới mọi user, phần group ngầm hiểu là mọi group |
%developers ALL=(ALL:ALL) ALL | Áp cho toàn bộ thành viên group developers |
trinity ALL=(aaron,jane) ALL | Chỉ chạy được lệnh dưới user aaron hoặc jane, không dưới root |
trinity ALL=ALL | Dạng viết gọn khi bỏ trường run as |
trinity ALL=(ALL:ALL) /usr/bin/ls, /usr/bin/stat | Chỉ được chạy hai lệnh trong danh sách |
trinity ALL=(ALL:ALL) NOPASSWD: ALL | Không bị hỏi password khi chạy lệnh sudo |
5. Truy cập account root
Cách tạm thời trở thành root đã xuất hiện ở mọi lệnh từ đầu tới giờ. Chạy một lệnh như dưới đây về bản chất là root nói: thực thi ls /root.
sudo ls /root
Nhưng khi muốn đăng nhập thành root chứ không chỉ chạy một lệnh, với một user có quyền sudo thì dùng:
sudo --login
sudo -i
Hai dạng trên tương đương. Thoát khỏi session root:
exit
Nếu user không có quyền sudo nhưng biết password của root, họ có ba lựa chọn, cả ba làm cùng một việc là đăng nhập thành root:
su -
su -l
su --login
Khác biệt nằm ở password được hỏi. Với sudo, hệ thống hỏi password của user hiện tại. Với su, hệ thống hỏi password của chính root.
Khi account root bị khóa
Một số hệ thống khóa sẵn account root vì lý do bảo mật. Việc đó không có nghĩa là account root không dùng được nữa, chỉ có nghĩa là không đăng nhập vào nó theo cách thường bằng password. Khi root bị khóa, sudo --login vẫn đưa vào được session root, vì password của user hiện tại không bị khóa. Nhưng su - thì không, vì nó đi hỏi password của root, mà password đó đang bị khóa.
Muốn cho phép đăng nhập thành root bằng password thì có hai tình huống. Nếu root chưa từng được đặt password, chọn một password mới cho nó:
sudo passwd root
Nếu root từng có password nhưng account bị khóa vì lý do nào đó, mở khóa:
sudo passwd --unlock root
sudo passwd -u root
Sau một trong hai bước đó, su - chạy được và nhập password của root là vào.
Tình huống ngược lại cũng gặp: hiện tại mọi người đăng nhập được thành root, nhưng xét lại thì thấy như vậy hơi mất an toàn. Khóa đường đăng nhập bằng password vào account root:
sudo passwd --lock root
sudo passwd -l root
Các đường đăng nhập khác vẫn có thể hoạt động nếu chúng được thiết lập trước đó. Nếu một người quản trị đã cấu hình đăng nhập bằng SSH private key, họ vẫn vào được kể cả khi account root bị khóa, vì phương thức đó không dùng password mà dùng khóa mật mã.
Trước khi khóa root, bảo đảm rằng user hiện tại chạy được lệnh sudo. Không có đường đăng nhập root và cũng không có quyền sudo thì không còn cách nào trở thành root, tự khóa mình ra ngoài và không sửa được các thiết lập hệ thống quan trọng nữa.
6. Quản lý user trên hàng trăm server và vai trò của LDAP
Theo mặc định, Linux lưu thông tin về user account và group ngay trên máy. User account được định nghĩa trong file /etc/passwd. Tên file dễ gây nhầm vì nghe như chỗ chứa dữ liệu password, nhưng nó chỉ chứa dữ liệu về account:
cat /etc/passwd
# Output (rút gọn):
aaron:x:1000:1000::/home/aaron:/bin/bash
Dòng này cho biết username, ID của user là 1000, home directory, và shell ưa dùng là /bin/bash.
Khó khăn xuất hiện khi quy mô lớn lên. Trong thực tế công việc thường phải quản lý hàng trăm server, và việc theo dõi xem account cùng group nào đang tồn tại trên từng hệ thống trở thành một gánh nặng, kể cả khi đã có công cụ tự động hóa như Chef, Ansible hay Puppet. Càng vất vả hơn nếu liên tục phải tạo account mới, gỡ user không còn dùng, định nghĩa group mới và tương tự.
Lấy một ví dụ cụ thể: một người mới vào nhóm, và cần tạo một account riêng cho người này trên 200 server. Thay vì đi cập nhật account trên hàng trăm máy, cấu hình chúng khác đi ngay từ đầu sẽ gọn hơn nhiều, và thứ cần thêm vào là một LDAP server.
LDAP viết tắt của Lightweight Directory Access Protocol. Các hệ thống Linux cấu hình được để dùng một LDAP server làm nguồn thông tin bổ sung cho user và group account. Nhờ vậy, mỗi lần cần thêm, gỡ hay sửa account và group, không phải thay đổi gì trên hàng trăm server riêng lẻ. Chỉ cần cập nhật dữ liệu về các account đó ở một nơi tập trung duy nhất, trên LDAP server, và các server Linux tự lấy dữ liệu mới mỗi khi cần.
7. Dựng LDAP server thử nghiệm bằng LXC
Bắt đầu bằng cách kiểm tra hai danh tính:
id john
id jane
# Output:
id: 'john': no such user
id: 'jane': no such user
Hai account này chưa tồn tại trên hệ thống. Cuối phần sau sẽ quay lại đúng hai cái tên này để thấy khác biệt.
Trong thực tế, việc quản lý LDAP server có thể không thuộc phạm vi trách nhiệm của người quản trị Linux: server đó có thể đang chạy trên Microsoft Azure hoặc trên một Windows Server, còn công việc ở đây là quản lý các server Linux. Trường hợp đó, phần phải làm chỉ là cấu hình các client để chúng dùng LDAP, chứ không phải dựng chính LDAP server. Nghĩa là phải hướng dẫn toàn bộ server Linux đi hỏi danh tính user và group từ một LDAP server tập trung.
Để tránh phải dựng một LDAP server từ đầu, một quy trình khá phức tạp, phần thực hành này dùng một bản đã cấu hình sẵn. Công cụ chạy nó là LXC, viết tắt của Linux Containers.
💡 Hình dung: LXC giống Docker nhưng cho cả một operating system thay vì cho một ứng dụng đơn lẻ. Cùng ý tưởng container, chỉ khác phạm vi thứ được đóng vào trong đó.
Trước tiên khởi tạo LXD, tức hypervisor giám sát các LXC container:
lxd init
Ở mỗi câu hỏi hiện ra, bấm Enter để chọn giá trị mặc định ghi trong cặp ngoặc vuông. Nếu tự thử lại, chú ý rằng kích thước tính theo gigabyte của loop device mới phải từ 5 GB trở lên. Đó cũng là giá trị mặc định trong trường hợp này, nên bấm Enter cho cả tùy chọn đó.
LDAP server dùng cho phần thực hành này do KodeKloud dựng sẵn ở dạng rất đơn giản và đóng vào một archive. Xem thử các file đang có:
ls
# Output (minh họa):
ldap-server.tar
Trong tar archive đó là Linux container image. Khôi phục image vào hệ thống:
lxc image import ldap-server.tar --alias ldap-server
Sau khi tiến trình import chạm 100%, vẫn phải chờ thêm một lúc tới khi nó hoàn tất việc thiết lập Linux container. Dấu hiệu nhận biết đã xong là command line prompt hiện ra trở lại.
Liệt kê các Linux container:
lxc list
# Output (minh họa):
+-------------+---------+------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------+---------+------+------+-----------+-----------+
| ldap-server | STOPPED | | | CONTAINER | 0 |
+-------------+---------+------+------+-----------+-----------+
Container tên ldap-server đang ở trạng thái stopped, nên khởi động nó:
lxc start ldap-server
Đến đây đã có một LDAP server dùng được. Để tiện cho việc thử nghiệm, mọi password trên nó đều được đặt thành đúng chữ password. Không an toàn, nhưng tiện cho mục đích minh họa. Muốn thêm dữ liệu vào LDAP server thì password của admin là password, và password của hai account Linux định nghĩa trên đó, john và jane, cũng là password.
Liệt kê container lần nữa và copy lại địa chỉ IPv4, vì bước sau cần tới nó:
lxc list
# Output (minh họa):
+-------------+---------+----------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------+---------+----------------------+------+-----------+-----------+
| ldap-server | RUNNING | 10.206.7.112 (eth0) | | CONTAINER | 0 |
+-------------+---------+----------------------+------+-----------+-----------+
8. Cấu hình client để lấy user và group từ LDAP
Có nhiều cách cấu hình hệ thống Linux để dùng user và group account định nghĩa trên LDAP server. Cách dưới đây có lẽ là cách dễ nhất: cài package libnss-ldapd.
sudo apt install libnss-ldapd
Chú ý tên package là libnss-ldapd với chữ d ở cuối. Còn có một package tên libnss-ldap không có chữ d đó, nhưng bản kết thúc bằng d có một số cải tiến so với bản kia.
NSS viết tắt của Name Service Switch, một cơ chế để Linux lấy dữ liệu về nhiều thứ khác nhau từ nhiều nguồn khác nhau. Mỗi khi hệ thống Linux cần thông tin về những thứ như user account, group, password hay hostname, nó tra Name Service Switch để biết phải lấy dữ liệu đó từ đâu.
Ba bước trong wizard cài đặt
Sau khi lệnh cài chạy, một install wizard có hướng dẫn hiện lên, giúp truyền vào các tùy chọn cấu hình. Chú ý phần chữ đỏ được làm nổi ở phía trên mỗi bước.
Bước thứ nhất cấu hình cho NSLCD, tức Name Service LDAP Daemon, thành phần chịu trách nhiệm lấy dữ liệu từ LDAP server. Chỗ này cần điền địa chỉ IP của LDAP server: thay IP ví dụ 127.0.0.1 bằng địa chỉ IP thật của LXC container đã copy ở phần trước, rồi thêm một dấu gạch chéo phía sau địa chỉ, đúng như trong ví dụ có sẵn.
ldap://10.206.7.112/
Bấm Enter để sang bước cấu hình tiếp theo: chọn distinguished name của LDAP search base. LDAP lưu được thông tin cho rất nhiều bộ phận trong một tổ chức, nên mọi thứ được chia theo cấu trúc dạng cây. Bước này là chỗ nói cho name service lookup daemon biết nhánh nào của cây đó đang chứa thông tin về user và group Linux. Phần text gợi ý trong wizard có sẵn một ví dụ.
LDAP server trong Linux container này được cấu hình để giữ thông tin user và group trong một nhánh nằm dưới domain name kodekloud.com. Các thành phần của domain đó là kodekloud và com, nên sẽ có hai domain component, viết tắt là dc:
dc=kodekloud,dc=com
Trong một số trường hợp, LDAP server còn lưu thông tin cho cả subdomain, ví dụ users.kodekloud.com. Nếu vậy thì phải thêm một component nữa vào đầu, chứa tên của subdomain đó, tức dc=users, và kết quả tương ứng với users.kodekloud.com. Ở đây không cần tới subdomain, nên xóa component đó đi rồi bấm Enter để sang bước kế tiếp.
Bước thứ ba là chỗ nói cho hệ thống Linux biết nó tìm dữ liệu bổ sung về user và group account ở đâu. Trong danh sách hiện ra, passwd ứng với dữ liệu user, group ứng với dữ liệu về group, và shadow liên quan tới password. Tích vào ba hộp đầu tiên đó, nghĩa là thông báo cho nsswitch.conf rằng dữ liệu user, group và passwd không chỉ nằm trên máy mà còn nằm trên LDAP server. Danh sách này còn kéo xuống khá dài, nhiều mục hơn những gì nhìn thấy trên màn hình, nhưng không cần bật tra cứu LDAP cho các mục còn lại vì phần này chỉ quan tâm tới user và group account. Bấm Enter để kết thúc cấu hình.
Hai file mà wizard đã sửa
Từ output có thể thấy ngay wizard đã sửa file /etc/nsswitch.conf, viết tắt của Name Service Switch. Xem file đó:
cat /etc/nsswitch.conf
# Output (rút gọn):
passwd: files systemd ldap
group: files systemd ldap
shadow: files ldap
Chữ ldap được thêm vào ba dòng trong file, tương ứng với ba hộp đã tích trong wizard. Dòng đầu tiên nói cho Name Service Switch biết rằng khi đi tìm dữ liệu passwd, tức dữ liệu về user, nó tìm được thông tin này ở ba nơi: trong các file mặc định như /etc/passwd, rồi một phần dữ liệu user có thể do systemd cung cấp, và cuối cùng dữ liệu user hợp lệ cũng có mặt trên LDAP server.
Nhưng file đó chỉ thông báo cho Name Service Switch biết nó lấy dữ liệu được từ đâu. Tự nó không lấy được dữ liệu từ LDAP. Việc đó thuộc về thành phần còn lại là nslcd: Name Service LDAP Daemon lấy được dữ liệu từ LDAP server, và file cấu hình chính của nó nằm ở /etc/nslcd.conf. File này cần quyền root mới đọc được:
sudo cat /etc/nslcd.conf
# Output (rút gọn):
uri ldap://10.206.7.112/
base dc=kodekloud,dc=com
Những thứ đã nhập trong wizard được lưu vào đây, gồm địa chỉ IP của LDAP server và các domain component dc=kodekloud với dc=com. Đây cũng là file để sửa khi cần thay đổi hoặc tinh chỉnh thiết lập về sau.
Kiểm tra kết quả
Hai account john và jane không có trên hệ thống lúc đầu phần này. Nhưng trên LDAP server đã cấu hình sẵn thì cả hai đều có định nghĩa. Chạy lại đúng hai lệnh ban đầu:
id john
id jane
# Output (minh họa):
uid=1101(john) gid=1200(ldapusers) groups=1200(ldapusers)
uid=1102(jane) gid=1200(ldapusers) groups=1200(ldapusers)
Hệ thống đã biết về các account bổ sung này. Trên LDAP server, cả hai user được đặt vào một group tên ldapusers. Cách sắp xếp đó chỉ nhằm cho tiện, để dễ nhận ra user nào được định nghĩa tại máy và user nào được định nghĩa trên LDAP server, còn thực tế đặt họ vào group nào cũng được.
Xem toàn bộ user, gồm cả những người định nghĩa tại máy và những người định nghĩa trên LDAP server:
getent passwd
getent viết tắt của get entries. Lệnh này yêu cầu Name Service Switch hiển thị các entry thuộc mục passwd, lấy dữ liệu từ mọi nguồn mà nó có. Trong output, mọi user đều được định nghĩa tại máy, trừ hai người cuối là john và jane.
Muốn lọc output để chỉ thấy các entry từ LDAP server thì truyền option --service và nói rằng chỉ cần entry từ service ldap:
getent --service=ldap passwd
Lấy các entry group định nghĩa trên LDAP server:
getent --service=ldap group
# Output (minh họa):
ldapusers:*:1200:john,jane
Tự tạo home directory khi login bằng PAM
Nhìn lại các entry user ở trên sẽ thấy một chi tiết đáng chú ý. Trên LDAP server, các account này được tinh chỉnh thêm với dữ liệu về họ tên đầy đủ, home directory và shell. Nhưng có một vướng mắc: john lẽ ra có directory cá nhân ở /home/john, trong khi trên hệ thống này vị trí đó không tồn tại.
Tự tạo home directory cho từng người bằng tay sẽ quay về đúng khó khăn ở đầu phần LDAP, chuyện phải đi cập nhật hàng loạt server. Mỗi lần có người mới vào là lại cấu hình lại hàng trăm máy để tạo home directory cho họ.
Chuyện này cũng có cách xử lý đơn giản: dùng Pluggable Authentication Modules, viết tắt PAM. Mỗi lần có user đăng nhập, các module này tự động được kích hoạt. Phần việc còn lại chỉ là truyền cho chúng thêm một chỉ dẫn: tạo home directory khi có ai đăng nhập mà directory đó chưa tồn tại.
sudo pam-auth-update
Tích vào hộp bên cạnh mục Create home directory on login, rồi bấm Enter để lưu thay đổi. Thử lại bằng cách đăng nhập thành john:
sudo -i -u john
Nếu đã lâu không dùng sudo, có thể phải nhập password sudo của mình trước, đừng lẫn với password của account john đã nói ở phần trước. Tới lúc hệ thống hỏi password của john thì nhập đúng chữ password, vì đó là giá trị đã đặt trên LDAP server.
# Output (minh họa):
Creating directory '/home/john'.
Pluggable Authentication Modules đã làm xong việc của chúng: thông báo cho biết directory /home/john vừa được tạo.
Tới đây, nếu có 100 server Linux cấu hình giống nhau thì cập nhật user và group account cho toàn bộ chúng chỉ còn là một việc nhỏ. Đăng nhập vào LDAP server, cập nhật dữ liệu về các account, và cả 100 server Linux có ngay dữ liệu đó. Một nơi tập trung duy nhất để tạo, gỡ hay sửa user, password và group của Linux.
Điểm cần nhớ khi vận hành: nsswitch.conf chỉ khai thứ tự nguồn tra cứu, còn việc nối ra LDAP nằm ở nslcd. Khi id một user LDAP mà không ra kết quả, kiểm tra nslcd còn chạy hay không trước khi đi sửa nsswitch.conf.
Domain tiếp theo trong lộ trình là Networking, bắt đầu từ Part 5.1: Cấu hình IPv4/IPv6, network service, bridge và bonding. Phần nền về user, group và resource limit nằm ở Part 4.1: User, group, environment profile và resource limit.
Nguồn tham khảo
Nguồn gốc: Khóa "Prep Course - Linux Foundation Certified System Administrator (LFCS) Certification" — phần "Users and Groups" (quản lý user privilege với sudo và file sudoers; quản lý quyền truy cập account root; cấu hình xác thực tập trung với LDAP, Name Service Switch, nslcd và PAM), nền tảng KodeKloud. Giảng viên: Jeremy Morgan và Alexandru Andrei.
Fact-check:
sudo -iviết bằng chữithường (dạng dài--login);sudo -Ikhông tồn tại, bài giảng gốc đọc là "dash capital I" nên đây là lỗi nghe hoặc lỗi đọc. Nguồn:man 8 sudo, 2026-10-24.- Phần LDAP của khóa dùng stack riêng của họ Debian (
libnss-ldapd,nslcd,pam-auth-update); trên họ RHEL bộ tương đương làsssdcùngauthselect. Đáng lưu tâm vì từ 11/05/2023 đề thi không còn phụ thuộc distro. Nguồn: Linux Foundation — UPDATED LFCS Exam, 2026-10-24. - LXD dùng trong lab này đã đổi bối cảnh: sau khi Canonical thay đổi giấy phép và yêu cầu CLA, trixie là bản Debian cuối cùng còn đóng gói LXD, và người dùng được khuyến nghị chuyển sang Incus, bản fork cộng đồng có trong Debian từ trixie. Các lệnh
lxd initvàlxcdưới đây giữ nguyên theo bài giảng gốc. Nguồn: Debian Wiki — LXD, 2026-10-24.