AFS with Samba PDC

[Allan Bjorklund]

--On Thursday, September 16, 1999, 10:35 PM +1000 Johan Hedin
<johanh at fusion.kth.se> wrote:

> We resently upgraded from NFS to AFS at our site. We have used Kerberos 4
> (KTH-KRB) for a while now. For the Win95 clients, it's not a problem. Its
> relatively easy to patch the clear text password Kerberos 4 support in
> Samba to include AFS support as well. If no one done this, I will try to
> get time to test and submit a patch doing this. However, to make the Samba
> PDC AFS aware it's much more tricky. Has anyone done this?

    Yes, but what we've done is a bit ugly and we are looking for a better
way.

    We've written wrappers for the MS networking DLLs, so that when
a user attempts to contact a networked share, it first tries to
contact a daemon on the machine to pass AFS tokens (encrypted of course)
to the server, and for the server to pass the client a string to use
as a password (also encrypted).  This password is then passed to the
real MS networking DLL to use as the password (the remote daemon has
already inserted it into the SMB password file).  After authentication,
a snippet of code added to SAMBA loads the passed up AFS token from a file
maintained by the daemon.

    If the initial connection can not be made to the daemon, the wrapper
DLL falls through and normal MS authentication occurs.

    The drawbacks are, that everytime MS "tweaks" the networking DLLs, we
need to recode our wrappers.  Also, we are making a change to SAMBA that is
dependant on an outside daemon.

    We have a few new ideas that are being investigated right now, that
if they work, would eliminate our need for the network wrappers and making
code changes to SAMBA.

> If not I have
> two suggestion
> 
> 1. Store the users Kerberos passwords as srvtabs on the local disk of the
>    Samba PDC, and then obtain a ticket after the NT password validation is
>    done.

    The potential security breakdown here scares me.  Do you really want
to place the srvtabs for all your users on a machine where the users will
have the ability to manipulate files?  Who knows what clever little tricks
the less honest may discover.

> 
> 2. Run the Samba PDC with an common AFS ticket on the local Samba machine,
>    turn off wide links and tell the intereseted users to set the ACL such
>    that Samba can read and write on their directories. In this scheme
>    users must be prevented from mounting each other's volumes in their
>    homes.

    Which prevents collaboration between people.  The ability to share
data files with others is a feature users demand to have.  That is too big
of a lose. Also if that one global account is compromised you really
lose.

> 
> Comments?
> 
> 
> The second issue is with the ticket lifetime. After the ticket has
> expired, Samba should die forcing the NT machine to open a new connection
> with a new ticket. This is not a problem for NT choosing the first scheme
> above, but will be for the clear text password version.

    What if you also share local UNIX files?  Cut them off also?

    One of the design goals for the new authentication methods we're
working on, is to have a method of prompting the user to refresh their
expired tokens.

--Allan

  ===================================================================
  Allan Bjorklund                  |                  allan at umich.edu
  Systems Research Programmer      |           University of Michigan
  Research Systems UNIX Group      |               535 W. William St.
  Information Technology Division  |              Ann Arbor, MI 48103
  1-(734)-763-9391                 |                           U.S.A.
  ===================================================================