Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!wrdis01!gatech!purdue!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: Postscript
Message-ID: <1991Apr26.044349.5265@ni.umd.edu>
Date: 26 Apr 91 04:43:49 GMT
References: <47755@ut-emx.uucp> <51753@nigel.ee.udel.edu> <47941@ut-emx.uucp>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 23

In article <47941@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes:
>	How about a DPS
>	server that authenticates connections and file opens using Kerberos,
>	and then uses your Kerberos credentials on your behalf to open files? 

Wow, funny you should mention this.  We will most likely be using
Kerberos authenticated AFS on our NeXTs anyway.

There is a need for a real authentication mechanism to be in place to
solve this and many other problems.  And guess what, not all the
machines that have to do this are NeXT platforms.

All we need do now is to figure out how to shove enough of NetInfo out
of the way to make this work.  (How would you change your password on
the Kerberos authentication server with Preferences?  How about with
`passwd'.  Hmm..  And these are the obvious questions to ask.)

I also agree that a public/non-public switch on the window server is
not nearly fine-enough granularity.  I hope the problem is solved by a
real authentication mechanism (see above) where I can specify specific
*users* and not just a list of IP addresses that I "trust."

louie