Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Aug 2001 00:28:22 +0900 (JST)
From:      horio shoichi <horio@pointer-software.com>
To:        "Daniel O'Connor" <doconnor@gsoft.com.au>
Cc:        "Jonathan M. Slivko" <jslivko@blinx.net>, Erik Sabowski <airyk@sabowski.dhs.org>, freebsd-stable@FreeBSD.ORG, Gabriel Ambuehl <gabriel_ambuehl@buz.ch>
Subject:   RE: Re[2]: Any way to have multiple machines share a single pass
Message-ID:  <200108151528.f7FFSMT13456@byte.near.this>
In-Reply-To: <12490000.997622809@vpn86.ece.cmu.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Connor wrote on 20010813:
>On 12-Aug-2001 Brandon S. Allbery KF8NH wrote:
>>  Ken Hornstein's Kerberos FAQ might be of interest.  Also, there's a 
>>  (sketchy) description of setting up a realm in the heimdal info file.
>>  
>>  http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
>>  
>>  However, Kerberos is almost certainly overkill if all you're looking for is 
>>  distributed accounts; also, only the password is managed by Kerberos, 
>>  something else must be done to keep the rest of the fields in /etc/passwd 
>>  in sync between machines.  NIS is the correct answer to this one.
>
>So the best idea is NIS+Kerberos..
>Anyone got a tute on _that_ combo from hell? :)
>

Did you call me ?

NIS is good at sprinkling info, including passwords, over net. If the password
is really strong enough, I mean the cipher and quality of passwords, then NIS
is just fine. Recent password scheme allows md5 (FreeBSD, OpenBSD, Debian, as
I remember) so seemingly passwords may be conveyed with yp. However, strong
ciphers only protect strong passwords. Passwords are still subject to dictionary
attack. Strong ciphers only make brute force attacks difficult[0]. Most sites
fail on the second criterion. And a few of them worry leakage of (encrypted or
not) passwords. Passwd[1] is far more secure than NIS (note, however, I'm not
discussing security of NIS or rpc here).

Since maintainig passwd and password itself host by host is really painful,
here comes kerberos, which is good at keeping secrets as it is. Using kerberos
for real secret supplementing NIS makes much sense. Below I will describe
how to use NIS with the help of kerberos, eliminating passwords from passwd
and 'ypcat passwd'.

First of all you should be able to login with kerberos password at login
prompt, and if you use it, at xdm. Otherwise there is no way to remove
passwords from both passwd and NIS[2].

Since both NIS and kerberos are network applications, you have to prepare
against the disaster; you should have root password in passwd on every host.
Add NIS hooks on master.passwd and group files. Assuming root password is
fairly unpredictable, apply schg on passwd. Adding/removing users are done
on kerberos and NIS (you still have to mount and populate home directories,
though[3]).

Now NIS:

o You want carry only user accounts with NIS but not low numbered ones: create
  a separate set of passwd from /etc which contain only users, using
  uncrackable password field. Export passwd and group maps from it. To do this
  you also will have to tweak /var/yp/Makefile. To avoid duplicate passwd
  maintenance, NIS master should ypbind to the domain.

o Some hosts may not be kerbeors login ready, yet: Don't compromize. Such hosts
  must at least install kerberos (this is easier than said. Real calamity of
  kerberos is in its initiation, which isn't by any means sin of kerberos per
  se[3]). Local login should be done via local passwd containing additionally
  local users who stick to the host that doesn't contradict with yp (NIS
  hook must be there because of NFS and logins from the other hosts).
  Upon login, the user should get tgt.
  Another way is leave such hosts unattended; login via kerberised telnet[4],
  serve as X server if it needs display. This makes both parties happier.

Finally, server securities:

o KDC is designed to operate without login, at least in principle[5]. Logging
  in KDC is a really bad idea. Although /var/kerberos/principal.db (which
  is kerberos password file) can only be read by root, the ascii formatted
  dumps of which aren't.  I'm sure you will blush if you look into for
  example slave_dump.

o Contrarily, NIS maintenance needs editing local files on master server and
  do 'cd /var/yp; make' there. Since there is no secrets remaining on the
  server, there should be no reason to avoid logging in to it. It's just a
  matter of convenience. Having no secrets is good for health.


[0]No one seems certain of the strength of using password. Even though it is
   resilient against standard installed current version of crack and jack, 
   will it still be so given more dictionaries, variant parameters, future
   'enhancements' and other tools ?
[1]Passwd is a collective nown here to represent master.passwd, pwd.db,
   spwd.db, passwd, and even group files usually found on /etc.
[2]I'm glad to see recent addition of pam_kerberosIV.so.
[3]As I got used to kerberos, I was really amazed at the simplicity and
   elegance of the design which was done more than two decades ago.
[4]I know what you mean. But you have to maintain yet another secret, host by
   host.
[5]I'm curious why kprop wasn't designed to operate from outside of KDC.



That's all I am currently aware of; HTH

horio shoichi

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108151528.f7FFSMT13456>