[ Jarle Osmund V�gen ] > 'OpenLDAP with libnss-ldap and libpam-ldap' > on http://www.debianplanet.org
Nice, but simple article. When using LDAP as a substitute for NIS or distributed /etc-files, encryption is essential. I don't know if slapd in debian is compiled with TLS/SSL-support, but setting up an LDAP-server as a authentication-server without encryption is a Bad Idea(tm). (think telnet vs. ssh) I know Skolelinux is aware of this matter, but it cannot be mentioned often enough. The article refers to http://aqua.subnet.at/~max/ldap/ for further information. I have only skimmed it, but some config-choices seem a bit old-fashion(or wrong). Example: Both 'host' and 'uri' are defined in pam_ldap.conf. ldap_init(3) takes host and port as arguments. This is an LDAPv3 call. The URI-method is only supported by ldap_initialize(no man-page. look in ldap.h). One uses _either_ ldap_init(or ldap_open) _or_ ldap_initialize. I haven't looked thru the pam_ldap sourcecode in a while, but I guess the last of the two, given both in a config-file, will decide. (ldap_open and ldap_initialize will be depreciated in a later release.(ref. ldap_init(3)) That's one thing. Another is the use of "pam_password crypt" instead of "ssl start_tls". The author mention that there are no SSL/TLS-support in his config, but solving the plantext-problem by shipping crypts(or MD5-crypts) over the ether just isn't good enough(IMO). The article(http://aqua.subnet.at/~max/ldap/) also shows how to let root at certain machines change a users password. This may be a nice feature, but it involves leaving a file with the password to the LDAP-server on the machine. It is protected, yes, but security thru obscurity; you know where I'm going at. One should enable TLS(SSL is old-fashoned) in pam_ldap.conf, and either continue to send crypts or send plain-text passwords to the LDAP-server. If you want root at certain machines to get privileges on the LDAP-server, make an entry in your directory with ACLs that give you the same functionality(make an object which represent [EMAIL PROTECTED] with the crupted password to [EMAIL PROTECTED]). Do _not_ distribute passwords for a critical system like this. If a cracker got into a setup like this, he/she wouldn't need much system-knowledge to be a semi-root on your LDAP-server. If the directory is set up correctly, a system-admin would only need the root-password of the machine he/she's administrating. (I'm not sure *nix-tools would understand this new way of thinking password-change, but tools can be made.) I'm not sure this is helpful for any of you, but it can be viewed as a comment or something. I'm sure there are other things in both articles I would have commented on, but there are numerous articles like these, and all have a certain approach to making an LDAP-enabled system. -- Mathias Meisfjordskar Skolelinux-hangaround "If it works; HIT IT AGAIN!"
