[OpenAFS] Re: OpenAFS-info digest, Vol 1 #843 - 16 msgs

[Daniel Swärd]

> Perhaps you could set up an intermediate non-interactively-used UNIX print
> spooler box that has the keytab file as per above, but also acts as an LPD
> spooler gateway for all of your Novell queues. Then the interactive UNIX boxes
> don't need to have any keytabs -- they think that those print queues are
> remote LPD queues. This intermediary's LPD service runs authenticated
> via a keytab, and can then look at ~user/ and read files in ~user/.novell/
> to yank the username and password as it spools the job to novell-land.
> Since this intermediary box is not general purpose, only admins should
> be able to log into it (by SSH), so the range of possibilities to have root
> cracked on the box and the keytab exposed should be greatly reduced.

If I set up a remove printer-server, how do I forward information about
which user is spooling the job? I need that in a filter script with
nprint.
 
> Lastly, by default AFS client <--> fileserver interactions for file data is
> done in cleartext. Than can be changed to use some form of crypto
> (single DES?) by issuing an "fs setcrypt on" command after your LPD
> startup script obtains a token but before it performs the first interaction
> with the fileservers (i.e. before it starts up LPD). Since this file data
> involves passwords in your case, this would keep those passwords from
> flying around in cleartext as LPD reads 'em from AFS. But it would not
> help when the client user saves that file per se, so someone sniffing your
> AFS traffic could still possibly snake some cleartext passwords in this
> case.

I've set all workstation afs-clients to use encrypted file transactions.
Does that still put the ".nwclient"-files as risk?

	/Daniel