Subject: [netatalk-admins] Log files

From: "Ryan Schwartz" <[email-masked]>
Date: Wed, 11 Aug 1999 14:40:12 -0500

Found them - syslog for those of you who didn't know...

Next question - is there a script/app that anyone has to extract the
netatalk stuff from syslog and analyze it??

Thanks
~~~~~~~~~~~~~~~~~~~~~~
Ryan Schwartz
Pediatrics Computer Support
3-8818
~~~~~~~~~~~~~~~~~~~~~~

---

From: Vicki Brown <[email-masked]>
Date: Wed, 11 Aug 1999 13:26:23 -0700

I'm trying to build netatalk-1.4b2+asun2.1.1 for RedHat Linux (MkLinux).
It has failed to find des.h.

The only docus I found on DES were these from README.ASUN:

        i've added Randnum and 2-Way Randnum support. part of the code is
        compliments of<[email-masked]>. as afp doesn't do the
        fallback thing in case of failure, Randnum and 2-Way Randnum
        are only available via afpd.conf. To get them to work, each
        user must have a ~/.passwd file (not read-/writeable by anyone
        else) with a password. this is a potential security problem as
        root can read the password. this may be compensated, to some
        extent, by the fact that your password never goes onto the wire
        when mounting a volume.

        NOTE: you will need to get a copy of the des library if you
        don't already have one for this option to work. i got mine
        from <ftp://ftp.psy.uq.oz.au/pub/Crypto/DES/libdes-x.xx.tar.gz>

I have little interest whatsoever in users needing a ~/.passwd file; I
think that's silly. Especially in cleartext as I have no idea at this time
what the user's passwords are...

Someone please tell me why I should possibly want this when I have a
perfectly valid (er, encrypted) /etc/passwd file at hand?

Do I _need_ this (~/.passwd) in order to allow changing passwords via the
dialog? In order to not use cleartext passwords in the Chooser dialog.

Does anyone have pointers to more useful information or has someone
installed on RedHat AND has password changing AND has non-clear-text
passwords (afpd.conf works for you?)

-----
 //=\   Vicki Brown <[email-masked]>
 \=//    Journeyman Sourcerer: Scripts & Philtres
  //=\
  \=//     Scientific Programming <> Perl, Unix, Mac
   //=\     A little Web gardening on the weekends
   \=//
    //=\      Deltagen, Inc; 1031 Bing St, San Carlos, CA 94070

---

From: Vicki Brown <[email-masked]>
Date: Wed, 11 Aug 1999 14:12:18 -0700

At 13:42 -0700 8/11/99, a sun wrote:
> isn't this a faq? i know that it's showed up in the list numerous
> times.

I haven't been on the list numerous times (I ded search what I had, and I
haven't thrown anything away, but all I found going back to January was
"This is how it works" not "This is WHY it works this way".

>
> here's the deal: /etc/passwd keeps a 1-way hash of your password. you
> can't actually extract the real password from it.

OK. Logical. I can live with "cleartext" passwords.  We're inside the
firewall. Can this vary by user? If the user has a ~/.passwd file it's not
clear going over the wire? Or will I have to switch everyone to the
~/.passwd regime if any one (highly placed and VIP person complains?)

Is the ability to set a new password related to this?

Do I need to try again to build and install a newer version of netatalk
other than the (binary distribution of)
netatalk-1.4b2+asun2.0a18.2-oa1a.ppc in order to allow setting passwords? I
have source for netatalk-1.4b2+asun2.1.1. It claims to be building. Will
this give me what I want? Is there an easier way? (I really am loathe to
change out what's "working" now).

What the heck _is_ this "User Authentication Module" I keep getting yelled
at about, anyway?

> current development patchset also has support for it if you have
> access to the openssl libraries.

doubtful. That hard, I don't want to work. This is my _part-time_ job.
-----

---

From: a sun <[email-masked]>
Date: Wed, 11 Aug 1999 13:42:11 -0700 (PDT)

here's the deal: /etc/passwd keeps a 1-way hash of your password. you
can't actually extract the real password from it. the encrypted random
number authentication methods, on the other hand, need to use an
actual password to encrypt random numbers. see a problem? currently,
my patchset keeps that password in ~/.passwd. in the next release,
you'll be able to store everyone's passwords in a global afppasswd
file that only root should be able to read.

of course, that brings us to the next question: why isn't there an
authentication method that just passes an encrypted cleartext password
through? well, there is. it's called DHX (for diffie-hellman
authentication) and will be standard with the next appleshare client
from apple. it currently is available as a separate uam with 3.8.3. my
current development patchset also has support for it if you have
access to the openssl libraries.

-a

---

From: a sun <[email-masked]>
Date: Wed, 11 Aug 1999 22:48:07 -0700 (PDT)

it has to be set on a per-server basis. as noted in the readme, the
appleshare client will refuse to use anything but the encrypted random
number uams if they're offered. as the name implies, sending over an
encrypted random number is a pretty good way of authentication. it
only suffers from the fact that you need to know the password on both
sides for things to work. 

passwords can be set in one of two cases:
	  1) random number encryption. it modifies the ~/.passwd
	     file. 
	  2) if you're using pam, it will work for cleartext passwords
	     as well.

you probably should at least install asun2.1.3. it has fixes over
asun2.1.1. 

as you might guess from the name, user authentication modules are the
bits that grant or deny access to an appleshare volume. currently,
apple specifies guest, cleartext, 1-way random number, 2-way random
number, and diffie-hellman uams. other authentication methods also
exist. in my latest development snapshot, they're actually implemented
as modules.

it's really not that much work. you just download and install the
openssl libraries and change a single line in the main netatalk
Makefile.

-a

---

From: Ron Chmara <[email-masked]>
Date: Thu, 12 Aug 1999 16:14:44 -0700

> [email-masked]
>    clear going over the wire?

Not if you're using randnum.
Here's a simple explanation, which is not techncally accurate, but metaphorically
accurate:
Each machine (client, server) knows the password.
They both agree on a math problem, and use the characters in the password
to solve the problem. They exchange the solution to the math problem, not the
password.

> Or will I have to switch everyone to the

It is unrelated to /etc/password
Think of it as a password for a separate service.

-Bop