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 [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
