[OpenAFS] Re: Serving AFS to Windows boxes w/o OpenAFS client (Samba)?

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig08D06DA408335DD3C1749282
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12/15/2010 11:13 AM, Andrew Deason wrote:
> On Wed, 15 Dec 2010 10:35:19 -0500
> omalleys@msu.edu wrote:
>=20
>> You used to be able to do straight krb5 auth in samba like 3.0.12 or  =

>> so was the first version to support it and if you want me to look =20
>> -somewhere- I have a link for the "how-to".  Then you could probably  =

>> do the preexec to get the token. I never actually thought about that  =

>> part. The krb5 piece worked. I tested that a long while ago like =20
>> 3.0.24ish.
>=20
> Samba can do krb5 auth, but you would need the client to forward
> tickets, too, in order to get tokens. I find it less likely that Samba
> can do that, but I do not really know; maybe it can.

Its not a question of whether Samba can do it.  Its a question of
whether the SMB clients will delegate credentials and the answer is that
they do not.

The choices are to either configure Samba to require clear test password
authentication which permits Samba to acquire the AFS token on its own
using the user's name and password; or to use GSS/SPNEGO authentication
(either NTLM or KRB5) and then use kimpersonate to generate a token for
the user.  kimpersonate has the downside that it requires that the AFS
KeyFile be shared with Samba and if Samba is compromised the AFS key is
vulnerable.

Other things to be aware of:

 * Samba over AFS does not properly enforce Windows locking
   semantics which can result in data corruption from multiple
   clients accessing the same file (one via Samba, one not Samba)

 * Do not use the host name "afs" for your Samba server.  Doing
   so will cause severe problems when mixed with native clients
   that expect their UNC server name to be "AFS".

Jeffrey Altman


--------------enig08D06DA408335DD3C1749282
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJNCPEjAAoJENxm1CNJffh4hfMIALZnl/GSzOo0IoKjeG8UsqMl
TBMBnsYTuOPn5I/BEfiWDS5DMtHBfS5LBugOBcwLa/ndH27bU85Et5WOM8M80Ljn
dtsTU7SmEK4mBSZpUx55ko+WAh9QFHt+qwG6UU1WMszNmvGJ+4brnmMUl0ehB421
U3X9YRhyBU7X3Q6b5HYZcIurfOBBJTMS57MSfXOjVOpvD4T+t0h0jS2kHRSTrJNz
tAVC/zFFF/jnqJeXWgs+jd9giNlb8HhjV1HPlTx1FrvD2x4zetAND2PqrqW2QcHZ
3G5GtrD7fYJJYw+5CJL1HCUQwMoBgl7I4f7pyecCfB91i/M5gQo/RZixbPgWwUk=
=k3fo
-----END PGP SIGNATURE-----

--------------enig08D06DA408335DD3C1749282--