On Sun, Apr 07, 2002 at 08:14:26PM -0700, Luca Filipozzi wrote:
> Two choices (I like lists :) ):
>
> (1) use libpam-ldap:
i recommend this. Even though the current pam system is a pain to
modify.. if you modify one file and it gets updated in the package it
will nag about it.. you can't tell if it's a needed change or not,
luckily i have heard rumours about new design for the pam system and i'm
eagerly waiting for it to arrive =)
> (2) don't use libpam-ldap:
> You don't have to use libpam-ldap. You could just use
> libnss-ldap and have the ldap server transfer the password
> hashes to the workstations in the clear ... which is equivalent
> to NIS. You could also use libnss-ldap with SSL/TLS so that the
> hashes are transferred more securely (equivalent to NIS+).
i don't recommend the above to anyone (do as i say, not as i do.. =) it
will cause problems, you are forced to enter the database access
password to the configuration, which you will then need to make readable
to root, which in turn forces you to use nscd.
There is nothing wrong with nscd, it's just plain stupid.. if you have a
small database, there is no problem, but if you have a big database (max
cached entries +1) you might start running in to trouble. apparently the
caching mechanism is quite stupid and it can't just expire an entry
becuse someone needs a new one.. =(
this also allows crackers to access your userbase, unlike libpam-ldap,
where you are not forced to allow userpassword read access to the
database. The cracker just needs to hack this machine, read the password
from config and voila, ur nt3w0rk has been 0wn3d!
Sami
--
-< Sami Haahtinen >-
-[ Is it still a bug, if we have learned to live with it? ]-
-< 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C >-
Attachment:
pgpoggjRq1MFV.pgp
Description: PGP signature