> "GN" == Gamlem, Noralf <[EMAIL PROTECTED]> writes:
GN> Since we're discussing passwords, I have another idea:
GN> 1. Support personell might need access to the computer even if the
GN>user is
GN> in front of it or not (enter a password and they're on)
GN> 2. "Other" people could be gran
for other people from the support staff
who are not aware of the temporary change.
Michael
> -Original Message-
> From: Greg Breland [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 28, 2001 12:25 PM
> To: '[EMAIL PROTECTED]'
> Subject: Re: IDEAS... RE
ilto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 28, 2001 12:46 PM
> To: '[EMAIL PROTECTED]'
> Subject: SV: IDEAS... RE: TightVNC 1.2.2 released
>
>
> Since we're discussing passwords, I have another idea:
>
> 1. Support personell might need access to th
Since we're discussing passwords, I have another idea:
1. Support personell might need access to the computer even if the user is
in front of it or not (enter a password and they're on)
2. "Other" people could be granted access by another password AND only after
the user has accepted a connection
PM
To: '[EMAIL PROTECTED]'
Subject: IDEAS... RE: TightVNC 1.2.2 released
I would like to see the server lock the workstation or bring the screen
saver up (password protected) before viewer gets the screen. That way I
could have null passwords at VNC level and still require authent
I don't think either of these is a good idea for several reasons:
1) How is a screen saver password any different that no screen saver with
a VNC password? VNC passwords are just as easy to set/change as a screen
saver password. If the server initiated the screen saver before the
client connect
I would like to see the server lock the workstation or bring the screen
saver up (password protected) before viewer gets the screen. That way I
could have null passwords at VNC level and still require authentication if
workstation is set with password protected screen saver.
Also, how about mult
