Re: [netatalk-admins] DES, how to log in


Subject: Re: [netatalk-admins] DES, how to log in
From: Mike (dugan@libwais.sonoma.edu)
Date: Sun Oct 04 1998 - 20:09:26 EDT


No answers, just some comments...
(See below)

On Mon, 5 Oct 1998, Cameron Hart wrote:
> Subject: Re: [netatalk-admins] DES, how to log in
> Hi again,
[chop]
> Previously, my options were the same as yours, except for -norandnum. I
> had -randnum
> enabled. Turning this off made password changing work for me. Seems
> wierd I thought it
> would have just defaulted to 2 way randnum for changing pw anyway?
[chop]
> When I tried to change the password with cleartext enabled and randnum
> disabled, I got
> an error message back saying something to the extent of ' invalid
> password', then I
> get disconnected. I'm not sure what is going wrong here. Again I can log
> in without a
> problem, but changing the password fails.

I do not yet know much about the ApleTalk protocol. I recently bougth the
book "Inside Appletalk", but I have not read it.

I made the assumption that netatalk would be susceptable to the same
backwards compatability for network sharing that the implementation of the
SMB protocol for Windows NT was:

... a client could request to use an older less secure protocol, and if
the server was configured to allow this kind of connection, it would be
allowed by default, unless specifically disabled...

I do not *know* if this is the case, but made the assumption that it was.
So I specifically disallow anything *but* 2-way rand, and none of the
appletalk users have shell access, so there are no valid password entires
for allowing them to ssh to the server. (Telnet, ftp, pop, sunrpc,nfs etc
are all disabled.)
This means that they must have ~/.passwd in plain-text, but no users with
shell access, and no passwords for these users existing in the the
passowrd file(s).

Using separate password files for shell users (me), netatalk users, and
samba users makes syncronization a problem for some, but I do not want any
shell account to have the same password as ~/.passwd or their unencrypted
smbpasswd file. Syncronization is not a problem from me. (Also, our users
either use Mac or PC for web page editing and file storage.)

I think that PAM is not needed if you just use 2-way-rand, since
/etc/shadow and /etc/passwd should not be consulted by netatalk when a
uaser needs to log-in. Changing of passwords should work as long as they
own ~/.passwd and have proper access to it.

If you *need* to have your /etc/passwd and /etc/shadow consulted and
modified via PAM wit netatalk, and users can log in, but cannot change
their password, then it is likely that you do have some problems with how
PAM support has been compiled into netatalk, or how it is configured on
your system. (Things that you are probably aware of which prompted you
to write your message... ;)

> I am using Shadow passwords and Linux PAM. My /etc/pam.d/netatalk file
> looks like
> this:
>
> #%PAM-1.0
> auth required /lib/security/pam_pwdb.so shadow
> account required /lib/security/pam_pwdb.so
> #password required /lib/security/pam_cracklib.so
> #password required /lib/security/pam_pwdb.so shadow use_authtok
> session required /lib/security/pam_pwdb.so
>
> I don't really know much about PAM, so maybe I am missing something here?

I have not done much work with PAM yet either. I have not had the need to
implement it with netatalk... Yet.

At this point, I will step out of this thread, since I can't offer much in
the way of support with PAM and netatalk on this.

Is anyone else willing to step in and help Cam with questions of password
changing with netatlk when /etc/passwd and /etc/shadow are access via PAM?

>
> Thanks,
>
> Cam.
[chopped all previous]

--------------------------------------------------------------------------
Systems Department Operating Systems Analyst for the Ruben Salazar Library
              of California State University at Sonoma.
  /UNIX(/BSD/SysV)\N_NW[.]VMS\WNTS\WNTW\W95\W311\WFWG\DOS:MacOS/NeXTSTEP
--------------------------------------------------------------------------



This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:23 EST