Lý sự pclouds

Trước mắt loại Common Lisp vì

• To quá
• Không thể tạo một chương trình nhỏ nhắn xinh xắn

Chuyển qua Scheme. Phải nói mặt trận Scheme còn rối hơn xử lí tương thích giữa các bản UNIX khác nhau. Mỗi bản cài đặt Scheme đều có những mở rộng riêng, do các chuẩn RnRS (mới nhất R6RS) không bao quát hết. Hai lựa chọn cuối cùng là Bigloo hoặc Gambit-C (PLT Scheme có vẻ cũng ngon). Bigloo đang tiến theo con đường Common Lisp khi có vẻ có quá nhiều thứ. Với lại cái object system của Bigloo trông... xấu.

Túm lại là hiện thời cứ Gambit-C mà chơi.

Hôm nay lại lên cơn sảng Lisp. Cài slime vào nhưng bị vướng bug 208522. Nào có hề gì. Dù trình độ Lisp của ta chỉ đủ để hù thiên hạ, ta vẫn đủ thời gian để "man lisp" rồi bắt chước chỉ dẫn trong bug 196665 để chạy được slime.

Ôi... đê mê. Tab tab, ngoặc, enter, help.. nước miếng pha nước mũi (cộng với "nước" mồ hôi do trời nóng quá) khi bắt chước làm theo cái Lisp for the Web. Đồng thời phát hiện ra mấy cái răng nanh của mình thật là lợi hại trong việc mở hộp bắp rang, chả cần dao kéo gì sất.

Năm ngoái cũng sảng một lần nhưng coi bộ cường độ lần này bị nặng hơn. Xong chỉ tiêu Lisp năm nay. Lisp lisp ơi là lisp lisp ơi... Lisp đi lisp đi lisp đi đừng ngại ngùng...

TB. Bữa nào chán Common Lisp, hay ta lại vọc Guile với Emacs? Dé!!!

Loạt bài chó gặm tuy có thể dùng để cài đặt một hệ thống hỗ trợ Kerberos và LDAP, tuy nhiên khá vất vả, hơn nữa lại không cơ động. Các thông tin đặc trưng hệ thống phải được lưu vào trong /etc/ldap.conf hay /etc/krb5.conf. Nếu điều chỉnh hệ thống, phải điều chỉnh tất cả các máy con. Điều này hoàn toàn không thể chấp nhận.

Cách tốt hơn là đi theo hướng Active Directory, thiết lập môi trường tuỳ vào hệ thống. Một hệ thống hoàn chỉnh sẽ bao gồm các yếu tố:

• Thiết lập cấu hình ban đầu
• Tự động quảng bá dịch vụ cho người dùng
• Xác thực một lần
• Quản lí Kerberos ticket

Phần thiết lập cấu hình ban đầu có thể nói là gay go nhất. Không có một chuẩn nào có thể được áp dụng cho phần này. Ta có thể điều chỉnh để đăng nhập với username dạng username@dns.domain.org, sau đó dựa vào SRV record để tìm ra các dịch vụ cơ bản đầu tiên (như Kerberos và LDAP). Sau đó PAM có thể được dùng để liên lạc (bằng cách nào không biết) lấy cấu hình cần thiết cho người dùng và cài đặt. Ở đây cấu hình khá linh tinh, như:

• nsswitch.conf
• GConf
• Sổ địa chỉ
• Thiết lập thư mục HOME trên máy con

Phần tự động quảng bá dịch vụ, có thể dùng zeroconf và SRV record. Các dịch vụ bao gồm đủ thứ như chia sẻ tập tin, SSH, remote desktop, web bookmark...

Phần xác thực một lần qua Kerberos cũng hết sức đau đầu, đã một lần bỏ cuộc cách đây hai năm vì Web (một mớ thứ như SPNEGO, SASL rồi GSSAPI...). Sau đó có đụng một tí XMPP với Kerberos. Phần chia sẻ tập tin, có lẽ vẫn chỉ là CIFS (đợi đến NFSv4 mới hỗ trợ Kerberos). SSH thì hỗ trợ Kerberos rồi. VNC/X11 nếu cần cứ tunnel qua SSH là xong.

Cuối cùng là vụ quản lí Kerberos ticket. Các môi trường làm việc như KDE hay GNOME đã hỗ trợ Kerberos chưa nhỉ? Như huỷ vé, hoặc vé hết hạn, hoặc... lấy hai vé một lúc...

Bài này về cơ bản kết thúc loạt bài chó gặm đã lê lết trong suốt tháng 4 này. Ở bài trước ta đã loại trừ đối thủ bên ngoài. Bài này sẽ cẩn thận với những kẻ tò mò ở bên trong.

Với openldap, phân quyền truy cập cây LDAP được thực hiện qua các chỉ thị "access to" trong slapd.conf. Chi tiết có thể xem man slapd.access. Ở đây chỉ đề cập một số ví dụ để làm quen.

Để hạn chế truy cập thông tin Kerberos:

# Chỉ users có quyền đọc, owner có quyền ghi
access to attrs=cn,givenName,sn,krbName,krb5PrincipalName,gecos
	by dn="<ROOT DN>" write
	by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
	by self write
	by users read

# Ai cũng có thể đọc, owner có thể ghi
access to attrs=loginShell,gecos
	by dn="<ROOT DN>" write
	by dn="uid=ldapadm.+\+realm=<<YOUR KERBEROS REALM>" write
	by self write
	by * read

# Không dùng userPassword, đơn giản là vì đang dùng Kerberos
access to attrs=userPassword
	by dn="<ROOT DN>" write
	by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
	by anonymous auth
	by * none

# User được đọc, còn lại cấm tất
access to attrs=mail,mailAlternateAddress,mailHost
	by dn="<ROOT DN>" write
	by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
	by users read
	by * none

# Chỉ có admin có thể ghi
access to attrs=mailQuota,trustModel,accessTo
	by dn="<ROOT DN>" write
	by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
	by self read
	by * none

# Admin có toàn quyền
access to *
	by dn="<ROOT DN>" write
	by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
	by * read

Loạt khai báo trên đa phần là "access to attrs=... by ... (read,write,none)", được dùng để phân quyền trên một loại thuộc tính nào đó. Phần "by" thông thường được kiểm tra dựa trên Bind DN thông qua by dn= (dĩ nhiên Root DN phải có quyền ghi trên toàn hệ thống, đó là lí do của dòng by dn="<ROOT DN>" write). Ngoài ra còn một số từ khoá có thể đi theo sau "by" như:

• anonymous là truy cập chưa được xác thực. "by anonymous auth" có thể hiểu đơn giản là cấm truy cập không được xác thực.
• users là bất cứ Bind DN nào đã được xác thực
• self là Bind DN phải trùng với nút đang cần sửa

Nếu không dùng Kerberos thì ít nhất cũng nên bảo vệ userPassword:

access to attrs=userPassword
	by dn="<ROOT DN>" write
	by anonymous auth
	by self write
	by * none

Để xác định cần bảo vệ những phần nào, chắc chỉ có cách đọc schema và xem xét từng thuộc tính một.

Đến đây kết thúc loạt bài chó gặm. Sau này có lẽ sẽ gặm tiếp một số mảng có liên quan đến LDAP khi có thời gian, ví dụ như:

• Chia sẻ tập tin
• Thư tín
• Sổ địa chỉ
• VPN

Để ý là từ đầu loạt bài LDAP cho chó gặm đến giờ, ta vẫn gửi dữ liệu qua mạng theo kiểu trần như nhộng. Trừ khi có áp dụng Kerberos thì phần xác thực sẽ đi tầng hầm, phần thông tin còn lại sẽ vẫn đi "mình ên".

Đến đây TLS/SSL vào cuộc (và cũng là nội dung của bài này). Cả TLS và SSL đều được dùng để:

• Bảo đảm hai đầu đường dây đều là phe ta (thường thì chỉ cần đúng "sếp" - server - mà ít quan tâm kiểm tra "lính" - client)
• Bảo đảm địch không thể nghe lén đường dây (mã hoá)

Trước hết hãy nói sơ khác biệt của TLS và SSL chút xíu vì hai thuật ngữ này thường đi kèm nhau. Nói một cách ba phải thì TLS và SSL không khác nhau mấy (trong RFC của TLS 1.0, số hiệu phiên bản được ghi là 3.1, bắt nguồn từ SSL 3.0). Theo đồn đại trên giang hồ (là Internet) thì SSL ra đời từ khi Netscape muốn kiên cố hoá http (sinh ra https). TLS ra sau này nhằm "chuẩn hoá" SSL, nhằm áp đảo và thay thế SSL, nhưng chỉ làm quần hùng rối thêm vì tới hai hảo hán. Các khác biệt của TLS và SSL tuy không nhiều lắm, nhưng đủ làm hai thằng không tương thích nhau. Nhưng cũng may là khác áo nhưng cùng ruột, hầu hết các bản cài đặt TLS cũng hỗ trợ SSL luôn.

Cái sự bắt tay giữa lính và sếp thông qua TLS/SSL cũng phức tạp (xem thêm trên Wikipedia, kiểm tra lại trong RFC). Đau đầu nhất là TLS/SSL sử dụng cơ chế khoá riêng/công khai để gửi mật mã dùng để mã hoá đường dây (đại loại là một bên sẽ phát sinh khoá, mã hoá bằng khoá công khai rồi gửi qua bên kia. Bên kia dùng khoá riêng của mình để giải mã lấy khoá mã hoá). Chính cái sự lằng nhằng này sẽ kéo theo một thứ mà ai cũng sợ khi phải đụng TLS/SSL: PKI(Public key infrastructure). Xây dựng PKI luôn là phần gay cấn nhất trong cài đặt TLS/SSL.

Trước khi qua PKI và certificate, nói luôn về StartTLS. TLS/SSL được thiết kế để bảo vệ đường dây ngay khi hình thành. StartTLS là một giải pháp kiểu như "nhấn nút A để mã hoá đường dây". Nói cách khác StartTLS được dùng để mã hoá được dây khi đã có trao đổi qua lại (chưa mã hoá) giữa hai bên. Để hỗ trợ StartTLS, đa số các giao thức đều phải cải tiến chút đỉnh. Lưu ý là vì StartTLS thường là "phần mở rộng", nó có thể bị bỏ qua nếu phía client tuyên bố "tao không biết StartTLS là gì, đừng đem ra hù tao". Và những client cà chớn kiểu đó sẽ buộc server truyền thông tin không được mã hoá.

Quay lại với PKI. Trong PKI, khoá công khai và khoá riêng, cộng thêm một số thông tin bổ sung, được gộp vào và tạo nên một thứ gọi là certificate. Có nhiều định dạng dành cho certificate nhưng nếu xài openssl kiểu nghiệp dư thì chỉ cần biết dạng "pem" là đủ. Certificate chứa thông tin bổ sung (như Common Name, sẽ nói sau) và khoá công khai. Thông thường khoá riêng nằm ở một tập tin "pem" riêng, tuy nhiên cũng có thể gộp thẳng vào certificate (không khuyến khích).

Certificate khơi khơi chưa đủ. Ai biết được cái khoá công khai mà thằng "sếp" đưa mình, kêu mình dùng để mã hoá bí mật, có thật sự là khoá của "sếp" mình? Nói cách khác, biết đâu đó là thằng sếp giả? Điều này dẫn đến việc phải chứng minh certificate của mình là "đồ xịn". Chứng minh bằng cách có một bên thứ ba công nhận certificate là "hàng hiệu". Bên thứ ba này là Certificate Authority (CA), còn cách để công nhận hàng hiệu là CA "kí tên" lên certificate. CA về bản chất cũng chỉ là một certificate, tuy nhiên cả client và server đều biết về CA từ trước, suy ra CA được ngầm định là đồ hiệu ngay từ khi chưa bắt đầu kết nối. Trên thế giới có một số CA "nhãn hiệu toàn cầu", bao gồm hạng nhà giàu như Verisign, hay hạng bình dân như cacert.org. Trong phạm vi "chó gặm", ta sẽ dựng CA riêng, thay vì đi mua certificate.

Xong mớ lí thuyết về TLS/SSL và PKI. Giờ ta sẽ bắt tay vô cày, thông qua OpenSSL. Các lệnh openssl được sử dụng là "openssl req" và "openssl x509". Để xem man page, dùng man openssl-req hoặc man openssl-x509, tương ứng. Phần ví dụ trong những trang man này rất thú vị, đáng xem.

Để hỗ trợ TLS/SSL ở mức cùi nhất, ta chỉ cần tạo một self-signed certificate và điều chỉnh chút đỉnh.

openssl req -new -nodes -x509 > cert.pem

Lệnh trên yêu cầu tạo certificate mới (-new) không mã hoá (-nodes), và tạo self-signed certificate chứ không phải certificate request (-x509). Ta sẽ cần nhập một số thông tin, quan trọng nhất là Common Name, phải là FDQN của LDAP server. Nó sẽ tạo ra certificate lưu trong cert.pem (khoá công khai kèm các thông tin linh tinh) và khoá riêng trong privkey.pem.

Để xem thử certificate mới cáu mình vừa tạo ra, dùng

openssl x509 -noout -text -in cert.pem

Để ý là hai tham số -in và -out của openssl chỉ là cách khác để khỏi dùng redirect (<cert.pem hoặc >cert.pem). Giờ quăng hai tập tin đó vào /etc/openldap (quăng chỗ khác cũng chả chết ai). Và điều chỉnh quyền truy cập. cert.pem thì dễ, ai muốn xem cũng được. Riêng privkey.pem thì LDAP server có quyền đọc nhưng không có quyền sửa. Nói nôm na là chown root:ldap privkey.pem;chown 740 privkey.pem. Xong thêm hai dòng vào slapd.conf:

TLSCertificateFile /etc/openldap/cert.pem
TLSCertificateKeyFile /etc/openldap/privkey.pem

Thêm một dòng nữa vào /etc/openldap/ldap.conf:

TLS_REQCERT  allow

Với cấu hình như thế, ta đã có thể dùng TLS/SSL. Để thử, dùng thêm tuỳ chọn -ZZ với ldapsearch, ví dụ:

ldapsearch -h mg.net -x -W -D "cn=Manager,dc=mg,dc=net" -ZZ

Tuy nhiên cách trên là cách... chó cũng không gặm. Nếu dùng ldapsearch với tham số -d 1 ta sẽ thấy thông báo certificate dỏm. Nếu chuyển dòng TLS_REQCERT sang hard ta sẽ... tiêu tùng (lỗi SSL3_GET_SERVER_CERTIFICATE certificate verify failed). Để chẩn đoán lỗi TLS/SSL, cứ dùng -d 1 trong ldapsearch.

Vậy ta cần mần cho ngon hơn, ta sẽ tạo CA. Như đã nói CA cũng chỉ là một certificate, nên cách tạo y chang như trên:

openssl req -new -x509 > ca.pem

Lưu ý là thông số -nodes biến mất, vì CA thì không ai lại để "khơi khơi" không mã miết gì cả. Bạn sẽ được yêu cầu nhập mật mã cho CA. Khi xong, đổi tên privkey.pem thành cakey.pem hay cái gì đó. Kế tiếp ta sẽ tạo certificate request thay vì certificate:

openssl req -new -nodes > cert.csr

Lần này thì thiếu -x509 (nghĩa là không muốn tạo cert, tạo cert request cơ). Nếu muốn xem lại cái request yêu dấu thì dùng:

openssl req -text -in cert.csr -noout

Sau đó ta sẽ "kí tên" khi nhận request và tạo certificate đã được kí tên đóng dấu (bởi ca.pem):

openssl x509 -req -in cert.csr -CA ca.pem -CAkey cakey.pem -CAcreateserial -out cert.pem

Cái tham số -CAcreateserial sẽ tạo ra CA.srl. Chả biết cái đó dùng làm gì, nhưng không có nó báo lỗi :( Vậy là xong, cert.pem cũng giống như cái self-signed certificate ta làm ở trên, khác ở chỗ có kí tên đóng dấu (cứ kiểm tra bằng "openssl x509 -text" nếu thích). cert.csr không còn giá trị gì nữa, xoá đi. Bước còn lại giống như trên, chép privkey.pem và cert.pem vào /etc/openldap và điều chỉnh cấu hình. Tuy nhiên có hai bước bổ sung

• Giấu biến cakey.pem đi. Bí mật quốc gia, cấm xem lẫn sờ!
• Thêm dòng TLSCACertificateFile /etc/openldap/ca.pem vào slapd.conf. Dĩ nhiên nếu ca.pem để chỗ khác thì điều chỉnh lại.

Giờ nếu ta chuyển TLS_REQCERT sang "hard" thì nó vẫn chết (lỗi "self signed certificate in certificate chain"). Ta cần phải cho client biết chỗ mò ra ca.pem nữa, vậy nên /etc/openldap/ldap.conf sẽ có hai dòng là

TLS_REQCERT  hard
TLS_CACERT /etc/openldap/ca.pem

Thêm cái TLS_CACERT cho từng máy một thì đúng là bưởi. Cách để khỏi thêm thì hơi tốn tiền: mua certificate của những CA danh tiếng như Verisign :)

Dĩ nhiên nếu để bảo đảm an ninh tối đa, mấy dòng trên chỉ là hình thức (kiểu như xây cầu rỗng ruột công nghệ VN). Muốn chắc ăn, phải hiểu rõ TLS/SSL các thuật toán mã hoá đi kèm, cái nào an toàn, làm PKI sao cho chắc, giấu cakey.pem chỗ nào... Chuyện đó, không phải dành cho chó gặm rồi.

(Trích "Alexis Zorba, con người hoan lạc")

Sẩm tối, chúng tôi rời nhà ông già. Zorba, lúc này cũng cao hứng, muốn nói chuyện cho đã.

- Hôm kia, mình nói chuyện gì, sếp hả? Sếp bảo sếp muốn mở mắt cho mọi người. Được thôi, sếp cứ thử đi mà mở mắt cho bác già Anagnosti xem! Sếp đã thấy bà vợ lão phải cung kính trước mặt lão như thế nào, chờ lệnh lão như con chó ăn xin đó. Cứ thử đi dạy họ rằng phụ nữ có các quyền bình đẳng với nam giới; rằng xẻo miếng thịt một con lợn mà ăn, trong khi nó đang còn sống rên xiết trước mặt mình, là tàn ác, rằng tạ ơn Thượng đế vì Thượng đế có đủ mọi thứ trong khi mình sắp chết đói, là điên rồ loạn trí! Thử hỏi cái lão quỷ già Anagnosti đáng thương sẽ rút được lợi lộc gì từ những lời giải thích bịp bợm của sếp? Sếp sẽ chỉ gây cho lão một lô băn khoăn lo phiền thôi. Và bà lão Anagnosti tội nghiệp được lợi lộc gì? Mỡ đã đổ vào chảo rồi, còn làm sao thay đổi được; gia đình sẽ bắt đầu lục đục, gà mái muốn giành ngôi gà trống, hai bên sẽ mổ nhau tơi bời, lông bay loạn xạ...! Cứ để mọi người yên, sếp ạ, đừng mở mắt cho họ làm gì. Và giả sử sếp làm được điều đó, họ sẽ nhìn thấy gì? Thấy sự khốn cùng của họ! Cứ để cho họ nhắm, sếp ạ, và để cho họ tiếp tục mơ màng!

Lão im lặng một lúc và gãi đầu. Lão đang ngẫm nghĩ.

- Trừ phi, cuối cùng lão nói, trừ phi...

- Trừ phi làm sao? Nói nghe nào?

- Trừ phi khi họ mở mắt, sếp có thể chỉ cho họ một thế giới tốt đẹp hơn cái bóng tối trong đó họ đang quanh quẩn... Sếp có thể làm thế được không?

Tôi không biết trả lời ra sao. Tôi hoàn toàn ý thức được cái gì cần được triệt phá, nhưng tôi không biết cái gì sẽ được xây từ đổ nát ấy. Theo tôi, không ai có thể biết chắc điều đó. Thế giới cũ là sờ mó được, vững chãi, chúng ta sống trong lòng nó và đang đấu tranh với nó từng giây từng phút - nó tồn tại. Thế giới của tương lai chưa ra đời, nó chuội đi như nước, không nắm được, nó được cấu tạo bởi cái thứ ánh sáng thường dệt nên những giấc mơ, nó là một đám mây bị xô đẩy bởi những cơn gió mạnh - yêu thương, căm ghét, tưởng tượng, may rủi, Thượng đế... Nhà tiên tri vĩ đại nhất trên trái đất chỉ có thể ban cho con người một khẩu hiệu thôi, không hơn, và khẩu hiệu ấy càng mơ hồ bao nhiêu, nhà tiên tri càng vĩ đại bấy nhiêu.

Zorba nhìn tôi với một nụ cười nhạo làm tôi phật ý.

- Tôi có thể chỉ cho họ một thế giới tốt đẹp hơn! Tôi đáp

- Thật ư, Tốt, sếp nói nghe nào!

- Tôi không thể nói được. Bác không hiểu đâu.

- Có nghĩa là sếp chẳng có thể chỉ ra được một thế giới nào hết, Zorba lắc đầu nói: Đừng có coi tôi là một thằng ngốc, sếp ạ. Nếu có ai đã bảo với sếp rằng tôi là một thằng ngu, thì người đó lầm. Tôi có thể chẳng có học vấn gì hơn lão Anagnosti, nhưng còn lâu tôi mới đần độn! Ờ, nếu tôi mà còn không hiểu, thì liệu sếp trông mong gì ở cái lão đáng thương ấy và mụ vợ dốt đặc cán mai của lão? Và còn tất cả các lão Anagnosti khác trên thế giới? Phải chăng sếp sẽ chỉ tổ làm cho họ thấy tăm tối hơn? Cho đến nay, họ đã xoay xở được kha khá; họ có con cái, thậm chí có cả cháu nội cháu ngoại. Thượng đế làm cho họ vừa mù vừa điếc, thế mà họ vẫn nói: "Tạ ơn Thượng đế". Họ cảm thấy thoải mái trong sự khốn cùng của mình. Vậy cứ để mặc họ và đừng có nói gì.

Tôi lặng thinh. Chúng tôi đang đi qua trước vườn mụ goá. Zorba dừng lại một lát và thở dài nhưng không nói gì. Chắc ban nãy vừa có trận mưa rào. Có một mùi đất ẩm mát rượi trong không khí. Những ngôi sao đầu tiên xuất hiện. Trăng non ngời ngời một vầng mơn mởn vàng xanh. Bầu trời tràn đầy dịu êm.

Con người này không hề cắp sách đến trường, tôi nghĩ thầm, và đầu óc lão không bị làm hỏng. Lão đã trải mọi chuyện đời, đủ vành đủ vẻ; tâm trí lão mở rộng và trái tim lão lớn lên mà không mất đi mảy may tính táo bạo ban sơ. Tất cả các vấn đề ta thấy phức tạp hoặc không thể giải quyết được, lão xử trí đánh xoẹt như lia một nhát gươm, kiểu Đại đế Alexandre chém phăng cái nút của vua Gordius. Thật khó mà khiến lão trật đích, bởi lẽ hai chân lão trụ vững vàng trên mặt đất bằng trọng lượng của cả thân hình. Những người mông muội ở chây Phi thờ rắn vì toàn thân nó tiếp xúc với mặt đất và do đó, hẳn nó biết tất cả những bí ẩn của trái đất thông qua bụng, đuôi và đầu nó. Nó luôn luôn tiếp xúc hoặc hoà làm một với Mẹ Đất. Zorba cũng vậy. Còn chúng ta, những người có học vấn, chỉ là những con chim đầu óc rỗng tuếch bay trên không.

Weekly chart tuần này có thể coi là tiêu biểu cho ba tháng gần đây (thậm chí 6 tháng):

• Persephone, Tristania và Draconian chiếm lĩnh 3 thứ hạng đầu, theo sau (xa xa) là Lacrimosa.
• Danh sách ban nhạc nghe trong tuần ngắn đáng kể, cụ thể tuần này chỉ có 6 ban. Nếu không kể phút bất đồng mở Metallica và ABBA thì có thể nói vừa đúng... bốn ban kể trên.

Hai điểm trên thể hiện một sự xuống dốc trong thưởng thức âm nhạc, thể loại nhạc giảm xuống còn đúng một loại. Nói theo kiểu ABBA là "I tried to reach for you, but you have closed your mind".

Tiêu rồi.

Tiếp tục chủ đề chó gặm, sau khi đã thử lưu dữ liệu Kerberos trên LDAP giờ ta thử theo hướng ngược lại: xác thực LDAP bằng Kerberos.

OpenLDAP không hỗ trợ xác thực trực tiếp bằng Kerberos. Thay vào đó dùng SASL(Simple Authentication and Security Layer) để xác thực. Một trong những cách SASL hỗ trợ là GSSAPI(Generic Security Services Application Programming Interface) được dùng để xác thực qua Kerberos.

Có khá nhiều tài liệu trên mạng đề cập đến vấn đề này (và cả TLS, sẽ nói sau). Hai bài khá hay là: Replacing NIS with Kerberos and LDAP và openLDAP installation.

Về cơ bản, ta sẽ phải tạo một principal cho LDAP server theo mẫu "ldap/sasl-host@sasl-realm" với sasl-host và sasl-realm là hai thông số khai báo trong slapd.conf (ví dụ "ldap/mg.net@MG.NET"), sau đó tạo keytab để truy cập principal này từ server (không cần quan tâm mật mã truy cập principal này). Cuối cùng ta cần chuyển đổi principal sang LDAP Bind DN.

Trước hết nói sơ qua quá trình xác thực dùng SASL/GSSAPI/Kerberos. Hiểu cách liên lạc giữa client và server sẽ giúp ích nhiều trong việc chẩn đoán và tìm lỗi.

• Sau khi đã kinit ta có vé TGT(Ticket Granting Ticket). Với TGT ta có thể nói chuyện với KDC để "xin vé" nói chuyện với những thằng khác, ở đây là LDAP.
• Vậy khi quá trình xác thực LDAP/SASL diễn ra, client sẽ đem vé TGT của mình đi gặp KDC xin vé ldap/<hostname>, trong đó hostname là FQDN(Full Qualified Domain Name) của LDAP server. Nói cách khác, hostname là A record trong DNS, không phải CNAME. KDC sẽ phát cho client vé này.
• Vé ldap/<hostname> này chỉ có LDAP server mới hiểu (do LDAP server có keytab, dùng để giải mã vé).
• Client gửi vé này đến LDAP server. Server giải mã vé và lấy được các thông tin cần thiết để định danh client. Nếu client được phép truy cập, quá trình xác thực hoàn tất
• Nếu client không có quyền truy cập, xui cho em rồi.

Vậy bước đầu tiên là tạo principal ldap/mg.net và keytab /etc/openldap.ldap.keytab cho server bằng kadmin.local (hoặc kadmin):

addprinc -randkey ldap/mg.net
ktadd -k /etc/openldap/ldap.keytab ldap/mg.net

slapd sẽ cần quyền truy cập ldap.keytab, vậy cho nó quyền truy cập giới hạn:

chown root:ldap /etc/openldap/ldap.keytab
chmod 640 /etc/openldap/ldap.keytab

Với cách phân quyền này, slapd hoàn toàn không có cửa thay đổi hoặc xoá ldap.keytab. Khi khởi động lại slapd, cần đặt biến KRB5_KTNAME là FILE:/etc/openldap/ldap.keytab để slapd biết keytab nào cần dùng. Với Gentoo thì đơn giản nhất là cho vào /etc/conf.d/slapd:

export KRB5_KTNAME=FILE:/etc/openldap/ldap.keytab

Tiếp đến là cấu hình slapd.conf, thêm một số dòng mới:

saslRegexp uid=([^/]*),cn=MG.NET,cn=GSSAPI,cn=auth uid=$1,ou=users,dc=mg,dc=net
sasl-host mg.net       # FQDN của LDAP server
sasl-realm MG.NET      # realm của Kerberos
sasl-secprops noanonymous,noplain,noactive # để tránh phải gõ -Y GSSAPI trong ldapsearch

man slapd.conf hoàn toàn không đề cập đến saslRegexp mà chỉ nói authz-regexp. Có lẽ hai cái tương đương nhau. saslRegexp dùng để chuyển DN tự phát sinh bằng SASL sang Bind DN thật trong hệ thống. DN tự phát sinh có dạng "uid=principal,cn=realm,cn=GSSAPI,cn=auth" (ở đây chỉ bàn SASL/Kerberos).

Với bao nhiêu đây thông tin và một phiên bản openldap hỗ trợ sasl, ta có thể thực hiện ldapsearch -h mg.net mà không bị hỏi han gì. Có thể thay mg.net thành IP nếu thích, nó sẽ tự động truy tìm ngược ra domain name.

pclouds@laptop ~/w/gentoo-x86 $ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
633 cgrep
497 ls
424 vi
340 v
298 fg
258 cd
210 ./cb
189 git
175 svn
142 rm

alias cgrep="LANG=C grep"
alias v="timestamp"
alias cb="Cui Bap"

Bài trước đã đề cập đến việc cài đặt Kerberos. Để tiếp tục loạt bài chó gặm, lần này ta sẽ nhét toàn bộ CSDL của Kerberos vào LDAP. Phải nói trước là chuyện trộn chung kiểu này có vẻ cũng không an toàn cho lắm.

Trước hết, cần phải cài đặt thêm plugin kldap cho kerberos (bản của MIT). Với Gentoo thì lên xem bug 177522 để có hỗ trợ LDAP. Với mấy thằng lười (slacker, e hèm) thì cấu hình --with-ldap và nhớ chép lại kerberos.schema để dành.

Lần này thì không thể bỏ qua kdc.conf nữa mà phải làm cho tới nơi tới chốn. Cấu hình khá lằng nhằng, kết quả sau cùng là thế này:

[libdefaults]
	default_realm = MG.NET

[realms]
	MG.NET = {
		admin_server = localhost
		kdc = localhost
		default_domain = MG.NET
		database_module = ldapconf
	}
[domain_realm]
	.mg.net = MG.NET

[logging]
	kdc = FILE:/var/log/kdc.log
	admin_server = FILE:/var/log/kadmin.log
	default = FILE:/var/log/mit-krb5.log

[dbmodules]
	ldapconf = {
		db_library = kldap
		ldap_kerberos_container_dn = ou=kerberos,dc=mg,dc=net
		ldap_kdc_dn = cn=Manager,dc=mg,dc=net
		ldap_kadmind_dn = cn=Manager,dc=mg,dc=net
		ldap_service_password_file = /var/lib/krb5kdc/service.keyfile
		ldap_server = ldap://localhost
	}

Khúc đầu thực chất là bản sao của krb5.conf, không có gì đáng bàn ngoại trừ dòng database_module tham khảo đến phần ldapconf trong dbmodules. Hai cái ldap_kdc_dn và ldap_kadmind_dn, chắc tới giờ ai cũng hiểu là Bind DN dùng để xác thực LDAP. ldap_service_password_file chứa thông tin mật mã đăng nhập LDAP (kiểu thường), sẽ nói đến sau. ldap_kerberos_container_dn là vị trí để lưu dữ liệu LDAP. Với mỗi realm, kerberos sẽ tạo một nút loại krbRealmContainer. Đây sẽ là nút cha chứa tất cả các principal. Mỗi principal sẽ là một nút con (loại krbPrincipal) với DN là krbPrincipalName=xxx,cn=realm,ou=kerberos,dc=mg,dc=net.

Đến đây ta có thể khởi động CSDL cho kerberos bằng lệnh sau (trong root). Tuy nhiên cần nhớ phải thêm kerberos.schema (đã nhắc ở trên, với Gentoo schema này nằm cùng chỗ với các schema khác) vào slapd.conf và khởi động lại slapd.

/usr/sbin/kdb5_ldap_util -D cn=Manager,dc=mg,dc=net -H ldap://localhost create -s

Có thể kiểm tra bằng ldapsearch xem nội dung mới đã được tạo thật sự hay không. Sau đó cần tạo service.keyfile

/usr/sbin/kdb5_ldap_util -D cn=Manager,dc=mg,dc=net -H ldap://localhost stashsrvpw -f /var/lib/krb5kdc/service.keyfile cn=Manager,dc=mg,dc=net

Phần cn=Manager,dc=mg,dc=net phía sau phải trùng khớp với ldap_kdc_dn và ldap_kadmind_dn ở trên. Bạn sẽ được yêu cầu nhập mật mã vài lần (một lần xác thực LDAP, hai lần nhập mật mã cho Bind DN để lưu lại)

Sau đó ta có thể dùng kadmin.local để thêm các principal đầu tiên như cũ. Không chạy được kadmin.local ở user thường (làm biếng tìm hiểu tại sao).

Cuối cùng là thử dùng kinit và klist để kiểm tra xem Kerberos hoạt động chưa. Chúc mừng bạn đã đăng quảng cáo Kerberos trên Những trang vàng! Ghi chú cuối cùng, lẽ ra phải cẩn thận giấu một số thông tin nhạy cảm như krbPrincipalKey. Chuyện này sẽ được giải quyết triệt để khi bàn đến phần đặt quyền truy cập của OpenLDAP.

TB. Thêm dòng sau vào slapd.conf để tăng tốc truy cập LDAP dùng cho xác thực Kerberos:

index   krbPrincipalName        eq

Phải nói con chó này hơi khó gặm. Thiết lập để cho kerberos chạy thì đơn giản. Cái khó làm làm cho nó an toàn. Mục đích của Kerberos là để an toàn, nếu thiết lập chính server kerberos chưa an toàn thì miễn bàn. Bét nhất thì cũng đọc Kerberos Infrastructure HOWTO

Thôi thì cũng mô tả ngắn để bà con (lười, giống tui) biết nó làm việc như thế nào.

Người dùng gửi principal của mình (là username á) đến KDC server. KDC server mã hoá "vé TGT" (Ticket Granting Ticket) bằng mật mã của người dùng, xong gửi ngược cho người dùng. TGT chứa "session key".

Người dùng dùng mật mã của mình để giải mã TGT lấy session key, xong gửi vé (mã hoá bằng session key) cho TGS(Ticket Granting Service) để xin vé truy cập các dịch vụ khác nhau.

Ấy là nói thế :) Phần này chỉ hướng dẫn sơ sơ cách cài đặt Kerberos dạng cơ bản nhất (nghĩa là dĩ nhiên không an toàn).

Trước hết là cấu hình chung (là cấu hình client, tuy nhiên server cũng xài ké) /etc/krb5.conf. Đây là phần cấu hình rất chán nên dán luôn, đỡ phải dài dòng:

[libdefaults]
	default_realm = MG.NET              # realm mặc định

[realms]
	MG.NET = {
		admin_server = localhost    # IP của kadmin
		kdc = 10.0.0.11             # IP của kdc
		default_domain = MG.NET     # domain mặc định của realm
	}
[domain_realm]
	.mg.net = MG.NET                    # ánh xạ domain sang realm

[logging]
	kdc = FILE:/var/log/kdc.log
	admin_server = FILE:/var/log/kadmin.log
	default = FILE:/var/log/mit-krb5.log

Có một qui tắc đơn giản là cứ lấy domain chính của hệ thống, viết hoa lên để làm realm (khá giống với khái niệm domain của Windows NT). Để ý là realm phân biệt hoa thường.

Xong, giờ đến khởi động cơ sở dữ liệu cho Kerberos, chuẩn bị chạy server

kdb5_util create -s

Nếu quên -s, lát nữa sẽ phải dùng kdb5_util stash để tạo lại. Stash là chìa khoá để kdc server nói chuyện với CSDL của nó. CSDL mặc định (trên Gentoo) nằm ở /var/lib/krb5kdc. Cấu hình kdc mặc định nằm ở /var/lib/krb5kdc/kdc.conf (không hiểu sao không cần cấu hình mặc định vẫn có thể tạo và khởi động kdc server).

Sau khi tạo CSDL xong, có thể tạo "principal" (user) bằng kadmin.local (chưa dùng được kadmin ở thời điểm này vì chưa chạy kadmin server, vả lại cũng chưa có principal nào được cấp quyền để sử dụng kadmin). Nhấn ? để biết chi tiết. Ta sẽ cần tạo hai principal là test/admin và test.

Sau đó, phân cho test/admin quyền tối đa, dùng để quản lí kerberos từ xa thông qua kadmin server, bằng cách thêm tập tin /var/lib/krb5kdc/kadm5.acl chứa dòng sau:

*/admin@MG.NET *

Xong. Cần cấu hình gì thêm thì man kdc.conf. Phần cấu hình server bây nhiêu đó, giờ chỉ cần khởi động server (thích thì khởi động kadmin, không cũng không sao):

/etc/init.d/mit-krb5kadmind start
/etc/init.d/mit-krb5kdc start

Đến đây, nếu tất cả ổn thoả, ta có thể thử kinit test và nhập mật mã tương ứng lúc tạo principal. kinit phải im lặng không nói gì, và klist phải liệt kê một "vé" ta nhận được.

Đấy! Dựng chó ba đầu chỉ có thế (nhưng đừng làm thiệt, coi chừng mấy thằng hacker nó đem con chó ba đầu "kiểng" đó đi làm mấy món thịt cầy đấy).

Sau khi gặm pam_ldap, nhai nsswitch.conf cũng dễ dàng.

/etc/nsswitch.conf là đầu mối một số thông tin quan trọng trên hệ thống, như cơ sở dữ liệu người dùng (passwd), thông tin nhóm (group), ánh xạ tên máy sang IP (hosts)... Do bài này hoàn tất phần đăng nhập của bài trước nên ta sẽ chỉ quan tâm đến mục "passwd" ("group" làm tương tự, khỏi chỉ).

Trước hết là điều chỉnh nsswitch.conf, kêu hệ thống, nếu không tìm thấy thông tin cần thiết trong /etc/passwd thì tìm trong LDAP, bằng cách thêm vào đuôi chữ "ldap":

passwd:      compat ldap

Xong. Việc còn lại là tiếp tục điều chỉnh /etc/ldap.conf để nss_ldap biết đường mò LDAP. Thông tin truy nhập LDAP server được dùng chung với pam_ldap, nên sẽ không cần điều chỉnh gì nữa. Ta chỉ thêm một số thông tin đặc trưng nss_ldap:

nss_base_passwd ou=users,dc=mg,dc=net # thông tin passwd lấy từ đâu

Với các CSDL khác như group, hosts... ta cũng chỉ cần uncomment dòng tương ứng và chỉnh base dn phù hợp. Mặc định nss_ldap dựa trên posixAccount để xác định thông tin. Với các loại CSDL khác, xem comment trong ldap.conf và man nss_ldap để biết cách cung cấp thông tin cho nss_ldap từ LDAP. Để kiểm tra, xoá dòng "test" trong /etc/passwd đi, kết quả của getent passwd test vẫn phải hiện được thông tin dành cho "test".

Lưu ý là /etc/ldap.conf sẽ được đọc mỗi khi một chương trình cần truy cập thông tin qua ldap. Do đó /etc/ldap.conf thông thường cần quyền 644 (nếu để 600 thì chỉ getent trong root mới hiển thị thông tin). Cũng bởi vì vậy nên càng phải khẩn trương giấu mật mã bindpw trong /etc/ldap.conf, nhưng đó là việc của bài khác.

Mặc dù bài này được viết sau, nhưng nếu bài trước không thành công thì có lẽ nên thử luôn qua bài này. Thiết lập nsswitch có điểm hay là có thể sử dụng strace getent để theo dõi, qua đó ít nhiều đoán được nguyên nhân lỗi ở đâu.

Bài kế tiếp trong loạt bài chó gặm này sẽ lý sự về chuyện đăng nhập vào hệ thống dùng LDAP, thông qua PAM(Pluggable Authentication Module).

Để đơn giản hoá, phần này sẽ chưa đụng vào nsswitch.conf. Do đó bạn sẽ phải tạo sẵn một user tên test. Nói chung là tạo tất cả những thứ cần thiết cho user test, bảo đảm user test có thể đăng nhập vô tư. Sau đó xoá mật mã của user test đi, vì ta sẽ sử dụng mật mã trong LDAP. Thông tin cơ bản, nói chung cũng chỉ cần một dòng trong /etc/passwd:

test:x:1001:100::/home/test:/bin/bash

Đồng thời tạo thư mục /home/test thuộc quyền của user mang UID 1001. Để ý là không cần một dòng nào bổ sung trong /etc/shadow, bởi vì ta sẽ không đăng nhập bằng shadow (nghĩa là mới đầu có dòng shadow, nhưng sau đó xoá dòng này đi để bảo đảm không còn đăng nhập được).

Chuẩn bị về cơ bản vậy là xong. Giờ cần cài đặt gói pam_ldap và gắn vào hệ thống PAM hiện có.

Trước khi điều chỉnh, cần nói qua một chút về PAM. PAM là hệ thống "canh cửa" cho Linux, chịu trách nhiệm xác thực, phân quyền, chuẩn bị linh tinh khi người dùng đăng nhập vào hệ thống. PAM thực hiện bốn khâu:

• Xác thực (auth). Kiểm tra xem mật mã người dùng đưa có đúng không.
• Tài khoản (account). Kiểm tra một số thứ linh tinh liên quan đến tài khoản. Ví dụ cấm đăng nhập nếu tài khoản không tồn tại, không hợp lệ...
• Mật mã (password). Phần này dành riêng cho việc đổi mật mã, chịu trách nhiệm cập nhật mật mã.
• Session, nhiệm vụ chính là chuẩn bị sẵn sàng để người dùng có thể sử dụng (ví dụ như hạn chế một số quyền của người dùng)

Thiết lập PAM nằm trong /etc/pam.d. Chính các chương trình sẽ quyết định mình muốn dùng tập tin nào trong thư mục đó. Tuy nhiên có một tập tin là /etc/pam.d/system-auth, được gộp vào tất cả các tập tin trong /etc/pam.d. Tập tin này đảm trách đăng nhập nói chung, không phân biệt chương trình nào dùng để đăng nhập. Ta sẽ sửa tập tin này để hỗ trợ LDAP.

Lưu ý là do system-auth tác động đến tất cả các hình thức đăng nhập. Sai sót khi điều chỉnh tập tin này có thể làm cho bạn không còn đường nào vào hệ thống ngoài việc dùng LiveCD. Do đó cẩn thận khi thao tác.

Sửa đổi trong tập tin này có thể nói là theo chuẩn. Nói chung cứ cắt dán là chắc ăn nhất.

auth       required     pam_env.so
auth       sufficient   pam_unix.so likeauth nullok
auth       sufficient   pam_ldap.so use_first_pass
auth       required     pam_deny.so

account    sufficient   pam_ldap.so
account    required     pam_unix.so

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2
retry=3
password   sufficient   pam_unix.so nullok md5 shadow use_authtok
password   sufficient   pam_ldap.so use_authtok use_first_pass
password   required     pam_deny.so

session    required     pam_limits.so
session    required     pam_unix.so
session    optional     pam_ldap.so

pam_ldap còn cần một số thông tin để biết cần liên lạc với LDAP server ở đâu, như thế nào. Các thiết lập này nằm trong /etc/ldap.conf. Thông tin cơ bản chỉ cần bây nhiêu đây:

host 127.0.0.1                           # máy LDAP nào
binddn uid=test, ou=users, dc=mg, dc=net # xác thực với DN nào
bindpw test                              # mật mã gì
scope one                                # chỉ tìm một cấp
pam_filter objectclass=posixAccount      # chỉ tìm những mục posixAccount
pam_login_attribute uid                  # thuộc tính nào là username
pam_password exop                        # cách cập nhật mật mã

Xem thêm man pam_ldap để biết chi tiết. Nhưng bây nhiêu là đủ để có thể vượt hàng rào "không có mật mã" để truy cập vào user "test". Nếu có trục trặc gì, xem /var/log/auth.log. Phải nhấn mạnh lại lần nữa là đến đây ta chỉ mới dùng thông tin userPassword trong LDAP thôi. Phần còn lại đều sử dụng thông tin hệ thống. Sau khi đăng nhập thành công, có thể dùng passwd để đổi mật mã (tuy nhiên đừng làm nếu theo đúng những gì được chỉ dẫn, test cũng chính là user được dùng để liên lạc với LDAP, nếu đổi mật mã thì phải sửa lại /etc/ldap.conf, kẻo pam_ldap hết đường nói chuyện với LDAP).

Để ý là mật mã được ghi "đường đường chính chính" trong /etc/ldap.conf. Dĩ nhiên cách này không hay, nhưng sẽ khắc phục sau, khi đã cài đặt Kerberos.

Vụ xoá mù này chỉ cần ghi vài chữ: Gentoo SELinux Handbook. Ai không quan tâm Gentoo, có thể bỏ qua phần đầu và bắt đầu đọc "Working with SELinux". Cuối phần này có tham khảo đến các tài liệu chi tiết hơn.

Cũng ráng ghi thêm vài chữ. Để kiểm tra máy có cài SELinux không, dùng sestatus. Nếu status là "enabled" và mode là "enforcing", chia buồn. Có thể tắt SELinux ngay bằng cách chuyển từ chế độ enforcing (cấm trong im lặng) thành permissive (không cấm nhưng lại la làng):

echo 0 > /selinux/enforce

/selinux xem trong sestatus. Khi chuyển qua chế độ permissive, SELinux sẽ rên la thống thiết trong kernel log (nghĩa là xem bằng dmesg). Trong mấy thông báo "avc" này thì scontext là "context" của chương trình truy cập, còn tcontext là context của đối tượng được truy cập. Nếu không muốn nhẫn tâm tắt SELinux thì nghĩa là sẽ có một số thứ cần làm. Trước hết là các thông tin cơ bản:

• Xem những module được nạp với semodule (tập tin có đuôi .pp)
• Xem "policy boolean" với getsebool
• Xem ánh xạ giữa username và SELinux identity bằng semanage user -l
• Xem cách đánh nhãn SELinux của tập tin với ls -Z
• Xem "đánh nhãn" tiến trình với ps -Z

Thông tin SELinux (context) trong hai mục sau là theo kiểu user:role:type. Trong đó user thường có đuôi _u, role có đuôi _r và type có đuôi _t.

Sau khi xác định được module cần nghi vấn, có lẽ sẽ phải kiểm tra mã nguồn của policy module tương ứng. Hai tập tin cần kiểm tra là .te chứa policy và .fc (file context). Biên dịch policy module (tạo .pp) được thực hiện thông qua makefile.

Để sửa đổi policy boolean, dùng setsebool. Để đổi role cho user hiện thời, dùng newrole. Để điều chỉnh file context, dùng setfiles (hay thấp hơn là restorecon).

Vậy ta tiếp tục cho chó gặm, lần này là LDAP schema.

Nếu đã từng tìm hiểu cài đặt openldap trên mạng, bạn sẽ thấy cấu hình slapd.conf khác đa phần có nhiều schema, không phải chỉ có mỗi core.schema. Schema là gì, để làm gì?

Schema chứa định nghĩa các thuộc tính (như dc, cn, o, objectClass...) và các objectClass (chả biết gọi sao cho đúng, chưa coi RFC). Mỗi objectClass sẽ qui định những thuộc tính nào là bắt buộc, những thuộc tính nào là tuỳ chọn. Các thuộc tính chưa được qui định bởi objectClass sẽ không được sử dụng.

objectClass "top" qui định thuộc tính bắt buộc là "objectClass"! Do đó top luôn luôn là objectClass bắt buộc. "dcObject" bắt buộc phải xác định thuộc tính "dc". Còn "organization" bắt buộc phải có "o" (kèm theo một mớ các thuộc tính tự chọn khác). Đọc mô tả objectClass không khó lắm, thành ra cứ vào /etc/openldap/schema và khám phá.

Đến đây coi như đủ để hiểu ba objectClass được sử dụng ở bài trước. Lần này ta sẽ tiến xa hơn tí bằng cách lưu thông tin đăng nhập của một user.

objectClass "posixAccount" qui định các thông tin cần thiết cho một tài khoản UNIX. "posixAccount" được định nghĩa trong nis.schema (nằm cùng chỗ với core.schema). nis.schema lại cần cosine.schema. Vậy nên slapd.conf sẽ được nới rộng ra tí để chứa thêm hai schema nữa:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/nis.schema

Trước khi thật sự thêm một user, ta hãy thêm một nút "organizational unit", để nhóm các user lại với nhau, dùng objectClass "organizationalUnit", với DN "ou=users,dc=mg,dc=net" và thuộc tính "ou: users".

ldapvi -D "cn=Manager,dc=mg,dc=net" -h localhost -o organizationalUnit

Có thể kiểm tra lại bằng ldapsearch cho chắc chắn. Đã đến lúc thêm một posixAccount, với nội dung sau:

add uid=test,ou=users,dc=mg,dc=net
objectClass: posixAccount
objectClass: top
cn: test
uid: test
uidNumber: 1001
gidNumber: 1000
homeDirectory: /home/test

Khi thử commit, bạn sẽ gặp thông báo lỗi "no structuralObjectClass operational attribute". Lí do là bất kì nút nào cũng cần một objectClass loại "structural" ("o" hoặc "ou" trong những lần trước). Trong schema, những objectclass loại này có chữ STRUCTURAL to đùng. Ở đây tui chọn "person" (vì chưa muốn dính dáng đến inetorgperson.schema). Kết quả thử lại với hai objectClass person và posixAccount:

add uid=test,ou=users,dc=mg,dc=net
objectClass: posixAccount
objectClass: person
objectClass: top
cn: test
uid: test
uidNumber: 1001
gidNumber: 1000
homeDirectory: /home/test
sn: test

Lệnh ldapvi tương ứng với nội dung trên thêm DN "uid=test,ou=users,dc=mg,dc=net" vào hệ thống.

Có một thuộc tính tuỳ chọn chưa được điền là userPassword. Bạn hãy sửa lại nút này và thêm thuộc tính userPassword là 'test'.

ldapvi -D "cn=Manager,dc=mg,dc=net" -h localhost '(uid=test)'

Giờ bạn có thể thay tuỳ chọn -D với binddn mới "uid=test,ou=users,dc=mg,dc=net" và dùng 'test' là mật mã. OpenLDAP sẽ dùng thuộc tính userPassword của nút được xác định bởi binddn để kiểm tra (bất kể objectClass của nút đó là gì). Để an toàn, nên dùng kết quả phát sinh bởi slappasswd thay vì lưu mật mã thô.

Xong. Bạn đã có thông tin của một user trong LDAP. Các loại thông tin khác như group... được qui định bởi objectClass trong các tập tin schema. Cứ việc đọc và khám phá.

Tiếp tục loạt bài LDAP cho chó gặm, bài này sẽ trình bày cách cài đặt OpenLDAP.

Nói chung làm cho OpenLDAP khởi động không có gì quá phức tạp. Sau khi đã emerge openldap (hoặc yum install openldap hay apt-get install openldap gì gì đấy), ta chỉ cần cấu hình một tí trong /etc/openldap/slapd.conf.

• Đặt đường dẫn nạp module modulepath /usr/lib/openldap/openldap
• Nạp backend hdb moduleload back_hdb.so
• Đặt thiết lập truy cập mặc định (access...), phần này chỉ đơn giản là bỏ comment, chả cần sửa đổi chi.
• Chọn dùng CSDL hdb database hdb
• Đặt suffix. Loạt bài này sẽ dùng suffix mg.net: suffix "dc=mg,dc=net". Nhớ để suffix trước checkpoint.
• Chọn rootdn rootdn "cn=Manager,dc=mg,dc=net"
• Đặt rootpw. Mật mã rootpw được phát sinh bằng slappasswd
• Lưu ý thư mục chứa dữ liệu. Trong Gentoo thì nó là /var/lib/openldap-data. Bảo đảm user được dùng để chạy slapd (trên Gentoo là ldap) phải có quyền truy cập thư mục này.

Cấu hình cuối cùng sẽ giống như thế này:

include		/etc/openldap/schema/core.schema

pidfile		/var/run/openldap/slapd.pid
argsfile	/var/run/openldap/slapd.args

modulepath	/usr/lib/openldap/openldap
moduleload	back_hdb.so

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
	by self write
	by users read
	by anonymous auth

database	hdb
suffix		"dc=mg,dc=net"
checkpoint	32	30 # <kbyte> <min>
rootdn		"cn=Manager,dc=mg,dc=net"
rootpw		không-ghi-ra-đây
directory	/var/lib/openldap-data
index	objectClass	eq

Sau khi hoàn tất /etc/openldap/slapd.conf, ta khởi động slapd. Với Gentoo, chỉ cần bỏ comment dòng này trong /etc/conf.d/slapd

OPTS="-h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"

Ngoài ra nhớ kiểm tra /var/run/openldap có thể truy cập với user ldap. Với các distro khác, tự tìm hiểu, hoặc cứ đặt biến $OPTS như trên rồi dùng slapd -u ldap -g ldap "$OPTS"

Kiểm tra nếu có tiến trình slapd là xong, đã khởi động thành công openldap server. Dĩ nhiên cái server này chưa có gì cả. Vậy hãy kiểm tra xem openldap có "dùng" được chưa bằng

ldapsearch -W -D "cn=Manager,dc=mg,dc=net"

Nếu sau khi nhập mật mã mà nó hiện ra tùm lum, không thấy báo lỗi là tốt. Cấu hình mặc định cho các tiện ích ldap* lưu trong /etc/openldap/ldap.conf. Ai thích thì vào đọc sơ và điều chỉnh cho phù hợp.

Nói thêm một chút về DN, "binddn", "rootdn" và "rootpw". DN đến giờ chắc ai cũng thấy nó là một chuỗi, cú pháp dạng a=b phẩy c=d... Bind DN là DN dùng như một "user", để xác thực với openldap. Root DN là một DN đặc biệt, giống như user "root" trong Linux. Root PW, dĩ nhiên là mật mã tương ứng với Root DN. Có một điều đặc biệt là đến thời điểm này, CSDL của openldap hoàn toàn không có gì. Có nghĩa là Root DN có thể là một chuỗi DN bất kì, không nhất thiết phải tồn tại trong CSDL của openldap. Nó chỉ đơn giản là một cái tên. Và bởi vậy nên muốn đặt sao cũng được (miễn vẫn là DN).

Rồi. Cần thêm một tí gì đó vào, chứ để LDAP trống rỗng thì chả cần chạy làm gì. Nếu can đảm, bạn có thể đọc man ldapadd và bắt tay viết tập tin .ldif. Nếu không, đã đến lúc dùng ldapvi. Hãy tạo mục đầu tiên (nút gốc). Gõ

ldapvi -D "cn=Manager,dc=mg,dc=net" -h localhost -o organization -o dcObject

Bạn sẽ thấy vim được chạy với một nội dung điền sẵn. Thay dòng add <DN> bằng add dc=mg,dc=net, thay dòng dc: bằng dc: mg và điền gì đó vào dòng o:. Kết quả cuối cùng đại loại là:

add dc=mg,dc=net
objectClass: organization
objectClass: dcObject
objectClass: top
o: Em G
dcObject: mg

Những dòng comment là thông tin mở rộng. Nếu thích thì cứ điền thêm (và bỏ comment). Lưu và thoát. Nhấn ? để xem trợ giúp nếu thích rồi chọn y để lưu. Xong bạn có thể kiểm tra lại bằng ldapsearch như trên.

Để điều chỉnh, dùng

ldapvi -D "cn=Manager,dc=mg,dc=net" -h localhost '(dc=mg)'

Phần (dc=mg) thuộc RFC 2254. Xem thêm nếu muốn.

Để xoá bằng ldapvi dùng (hoặc dùng ldapdelete):

ldapvi -D "cn=Manager,dc=mg,dc=net" -h localhost --delete dc=mg,dc=net

Không có nhiều thứ để nói ở thời điểm này. Bản LDAP server của bạn được cài đặt hết sức đơn giản, chưa hỗ trợ SSL. Thông tin LDAP cũng chưa có gì. Chỉ có một điều đáng lưu ý là cần tạo nút gốc có objectClass là "organization". Nếu base DN dài hơn (ví dụ dc=em,dc=yeu,dc=linux,dc=com,dc=vn) thì cũng chỉ cần tạo nút gốc ở dc=em. Nếu bạn thắc mắc tại sao cần objectClass dcObject, bạn có thể thử bỏ để nhận được thông báo "Name violation, additional info: naming attribute 'dc' is not present in entry".

1. Tổng quan
2. Cài đặt cơ bản
3. Schema, lưu thông tin đăng nhập
4. Đăng nhập
5. nsswitch.conf
6. Chó ba đầu
7. Chó ba đầu trên Những trang vàng
8. Single Sign-on
9. Bê tông hoá đường dây
10. Đề phòng nội gián

Loạt bày này sẽ trình bày các thiết lập LDAP để phục vụ cho vụ Single Sign-on. Để tiện xếp loại, loạt bài này cũng sẽ được phân loại Em G, một dự án giờ có thể nói đã đạt được một đẳng cấp nhất định ở... âm phủ.

Như tên bài đề cập. Đây thật sự là loạt bài "cho chó gặm". Nghĩa là cắn vào không thấy nhập nhụa thịt mỡ như bít-tết, mà toàn xương là xương. Bạn nào thích phong cách "OK OK Yes Yes Next OK Finish", có thể ngừng đọc ở đây. Nếu tiếp tục, bạn sẽ phải hiểu DN là gì, schema chứa cái gì, cách đọc schema, thiết lập PAM, NSS...

Vậy LDAP(Lightweight Directory Access Protocol) là gì? LDAP là một cái, đại loại như "Những trang vàng" (mà thật sự cũng có một cái na ná, NIS ban đầu được gọi là Yellow Page). LDAP là một nguồn cung cấp thông tin, khá giống với một hệ cơ sở dữ liệu quan hệ. LDAP thường được dùng để lưu các thông tin người dùng trong hệ thống, dùng như một nguồn xác thực, hoặc cung cấp sổ địa chỉ.

Hãy lấy một hệ cơ sở dữ liệu quan hệ (ví dụ MySQL) để so sánh với LDAP. LDAP có một số khác biệt:

• Được thiết kế để thiên về truy cập đọc, ít sửa đổi.
• Cấu trúc thông tin dạng cây. Thông tin được chứa trong một tập thuộc tính ở mỗi nút. Trái lại, một hệ RDBMS như MySQL cấu trúc thông tin theo hàng, chia ra nhiều bảng.
• RDBMS có khái niệm "key", và liên kết các bảng thông qua key để có nhiều thông tin hơn, từ nhiều bảng khác nhau. LDAP sử dụng khái niệm schema (hay objectClass). Mỗi nút có thể có nhiều objectClass. Mỗi objectClass (tương tự bảng trong RDBMS) mô tả một tập các thuộc tính. Vậy quay về góc nhìn của RDBMS thì LDAP đã kết hợp tất cả thông tin của các bảng rời thành một bảng duy nhất.

Ngoài các đặc điểm trên, LDAP còn có một số khái niệm cần nắm, như DN(Distinguised Name), rootdn, base, search scope, search filter). Có một vài LDAP server mã nguồn mở, như OpenLDAP, Fedora Directory Server hay Sun OpenDS. Loạt bài này sẽ theo hướng truyền thống hết sức “chó gặm” là dùng openldap.

Việc cập nhật LDAP thông qua các công cụ do openldap cung cấp, phải nói chó cũng không thèm gặm. Sử dụng ldapsearch, ldapadd hay ldapmodify là chuyện chẳng đặng đừng. Có một số dự án giúp đơn giản hoá công tác quản lí LDAP (mà vẫn chó gặm, nghĩa là không chơi GUI) như ldapsh, ldapfs. Tuy nhiên công cụ tui thấy lí tưởng nhất là ldapvi. Cứ hình dung thao tác crontab như thế nào thì sửa đổi ldap bằng ldapvi cũng rứa.

Vậy là thế. Bạn đã biết sẽ phải cài đặt openldap, sẽ cập nhật ldap bằng ldapvi (ldapsearch cũng được dùng). Ngoài ra sẽ cần thêm một số gói khác như pam_ldap, nss_ldap hay kerberos qua các bài sau.

Tin thứ nhất. Úi mèn ơi chuyện Epiphany đá đít em Tắc kè là thiệt! Phản ứng nói chung (tính luôn tui) là nhất trí. Hí hí...

Tin thứ nhì. Bạn Bi đã chứng tỏ mình lạc hậu một cách kinh dị. Trước nay chỉ biết dùng gentoo livecd để chạy "live". Chưa bao giờ biết có thể cài đặt hoàn chỉnh từ cái livecd đó mà không cần chép thêm cái gì khác. Hồi nào giờ chỉ biết phải móc portage snapshot và stage3 tarball về. Nhục ơi là nhục.

Tin chót. Ai dùng 360.yahoo.com, xin thông báo là trang 360 của tui đã bị đóng cửa vĩnh viễn. Mọi thông tin trên đó đã gửi gió theo mây ngàn bay. Và hình như cũng không thể liên lạc qua 360 nữa (nếu được nhớ nói, tui đóng nó luôn).

Tin chót chót. Vụ Samba/Active Directory lại khơi gợi máu Ác Min. Tiếp tục ngâm cứu cái Single Sign-on đã đình đốn trước đây, thử đưa ra một giải pháp "enterprise" cho Linux (và chỉ Linux).

Tin chót chót chót. Hình như câu này đã thành câu mời sinh nhật "chuẩn": "Nhan dip SN lan thu XXX cua tao, than moi anh em di du buoi tiec SN dam bac". Thêm hai thằng mời kiểu này nữa là coi như thành luật luôn.

Tin chót chót chót chót. May quá thông báo giới thiệu "Blue Moon" chưa vô thùng thư Spam. Phù... chắc cũng không ai nỡ quýnh thằng ròm như mình. Dây dưa với bọn Séc.. này nguy hiểm quá.

Làm sao cài đặt Samba server hoạt động độc lập trong môi trường Windows domain? Ý là chỉ cung cấp anonymous share, không cần xác thực lôi thôi với Active Directory. Sau một vài giờ mò mẫm, bí quyết để thực hiện là

map to guest = Bad User

Lí do đơn giản là do các máy khác đều đã vào domain, khi nói chuyện với Samba nó cũng khoe domain user của nó. Samba không hiểu, thế là Samba đá văng chúng ra. Hậu quả là không thể nào thiết lập anonymous share được (dù máy Linux truy cập thì lại tốt).

Với lệnh trên, tất cả các domain user đều được đánh đồng là guest. Cách nghe có vẻ bưởi nhưng lại hoạt động tốt. Dĩ nhiên cao cấp hơn là xác thực Kerberos và cho Samba server vào domain, nhưng chắc cái domain user của mình bị tắt mất rồi :( Tại thử sai nhiều quá. Hic... mai này làm sao em có thể dùng lại Windows đây? Khi account của em tiêu táng thoòng rồi...

Nhân tiện không biết bà con có biết cách các máy Windows tự tìm ra PDC, AD server như thế nào không?

Cá năm nay bắt đầu với tin kernel.org chuyển sang dùng FreeBSD, sau đó OSI tuyên bố thành lập Microsoft OSI.

Hai tin chấn động kế tiếp là việc Epiphany tạm biệt Tắc kè và Ubuntu đá văng FHS

Intel cũng làm một cú hoành tráng bằng việc chuyển chương trình đơn nhiệm thành đa nhiệm mà không cần sửa code. Cùng lúc, Dscho chán cày Git, quyết định mở công ty.

Gentoo không có một tin "chấn động" nào trong ngày này (nhớ hồi xưa có tin Portage được chuyển sang NT). Nghe đồn OpenBSD đã thành công trong việc chuyển driver 3D của ATI và Nvidia :)