[OpenAFS] Samba Gateway Update

Cameron, Frank cameron@ctc.com
Tue, 4 Sep 2001 19:02:57 -0400

First I'd like to list some of the limitations of the AFS
Client for Windows based on my experience deploying it to and
managing it on several hundred systems.  I make no attempt at
this time to elaborate on these or rank them; this is just
meant to provide some insight into my motivation to look into
the Samba gateway.

1>  File locking.  The lock of byte-range locking negatively
        impacts several common PC applications such as OutLook
        and Excel.
2>  Drive mapping.  Is not uniform across systems and GUI
        mapping relies on proprietary interface.
3>  Password changing.  Is not integrated with native GUI and
        provides no proprietary GUI.
4>  ACL management.  Is not integrated with native GUI and
        proprietary GUI lacks niceties.
5>  Reliability.  The gateway system for 9x access has not been 
6>  Remote access.  Using the NT client when not on the LAN
        requires special client side hacks.
7>  Client update.  How to update software and/or (more
        commonly/importantly) configurations?

The easiest way (and what I first attempted) to create such a
gateway is to simply use Samba's PAM support to handle the
tokens.  I'll use this method as the baseline for the promise
and pitfalls of AFS gateways.

1>  A recent Samba with file-locking support could alleviate
        file-locking problems with Windows applications.
2>  Drive mapping would be uniform across systems and use the
        native GUI.
3>  Remote access would behave more uniformly with-out the
        special hacks.
4>  The client piece is lighter (in this case, 0);
        configuration is on the Samba server and easily
5>  The Unix box running Samba should be much more reliable
        than the NT box running the standard AFS gateway.

1>  Issues with clear-text versus encrypted passwords.
2>  Can't manage ACLs.
3>  Can't change AFS password.
4>  Single point of failure.
5>  Can't renew or automatically obtain tokens.
6>  Lose local AFS cache.
7>  Can't manage personal groups.

My latest effort is using the Samba RPC Extension that was
posted to openafs-devel by Jason Robertson awhile ago.  Despite 
needing to hack the Makefile a bit to get Samba to compile
(Samba 2.2.1a on SlackWare 8 and RedHat 7.1 with OpenAFS 1.1.1) 
it seems to work well and address some of the above issues.

1>  Clear-text password problems are alleviated.
2>  Still can't manage ACLs. *
3>  Still can't change AFS password. **
4>  Can renew tokens but not automatically obtain them.
5>  The client side piece is still very light with most
        configuration on the server.  (See **)

*The ACL issue may be addressable by extending Samba's existing 
ACL support to support AFS ACLs.
**By adding kpasswd.exe and a few DLLs to the workstation I can 
build a light client that supports password changes.  This also 
requires a local CellServDB (afscell.ini) which is still
difficult to centrally manage.

The Samba RPC extensions + local kpasswd is very close to being 
a usable client.  The only piece really missing that's a show-
stopper (for me) is the automatic token grab at login.  (Few of 
my users need to manage groups and ACLs; but they all need to
access their files and change their passwords.)