Re: [Devel] ldap article on debianplanet
[ 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 root@machine
with the crupted password to root@machine). 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!"
Reply to: