Alex, I will be more than happy to keep everyone informed and document how this implementation goes. I'm not real keen on telnet myself. Although, that option has come to mind. As an alternative, I have considered installing SSH servers on all machines at the same time I install VNC. I have found that telnet is not secure at all. Its packet transmissions are sent in plain text which opens up a huge security hole in my situation. This allows your username, password, and commands sent to be viewed by anyone with a packet sniffer. This also opens up the possibility that your telnet session could be hijacked. SSH behaves just like telnet, only the entire session is encrypted. The reason I have so many layers of security is we plan to support the university's faculty and staff with this technology, but not the students. But, the students do have access to the same network as the faculty and staff which is a rather large security risk. At the same time, many political and legal issues have arisen from the faculty and staff about us being able to connect to their machines, so I have to take measures to cover ourselves.
Please let me know if anyone has any questions or comments on how I am doing this. Thanks, Nathan --- "Alex K. Angelopoulos" <[EMAIL PROTECTED]> wrote: > Nathan, > > it sounds like you have the core infrastructure in > place or planned to make VNC > behave in almost exactly the manner you want. > > I especially like two elements; forcing the routing > through one system, and the > dynamically generated database/web page - which I > don't recall seeing anyone do > before from a web server. I'm fairly certain is > *must* have been at least > attempted by someone by now, but it certainly isn't > documented... which is also > a hint that we would love to see your comments on > the process and details when > finished. :) > > One other thing if you have not already considered > it: it might be worthwhile > also enabling the telnet server on the Win2K/XP > systems. Since it sounds like > you're primarily a Unix/Linux guy, you are probably > already aware of details of > this, but just in case I'm mentioning some of the > details from my limited > experience below. This is also straying from the > pure VNC topicality a bit, but > you've already covered most of the details. > > + In practice, the telnet server on Win2K/XP is a > great tool for quick remote > access and spot-troubleshooting of services. It is > especially nice on XP since > the command line tools have been significantly > enhanced by a couple of people at > Microsoft who have been championing integrating > resource kit tools into the base > OS; taskkill and tasklist are especially handy for > terminating unresponsive > apps. Since VNC is very well-behaved service when > it comes to stop/restart > requests, a quick net stop/net start via remote > connection can handle any of the > potential odd issues for you. > > + Win2K and XP come with the telnet service already > available, but not running > by default. It also has NTLM authentication > configured as the standard form of > required authentication - I would advise disabling > that requirement. I would > also modify the behavior of the built-in telnet > clients , since they by default > attempt NTLM authentication first when trying to > telnet: this means they > transmit their password on a telnet connection > attempt. It is hashed, but the > hash can be cracked, which makes this a significant > security flaw in my opinion. > > + Going even farther afield from VNC-specific stuff > for this, the 2 standard > free telnet clients for Windows which also support > automation, TeraTerm and IVT, > are both extremely well-behaved on Win2K and XP - so > if you want to ditch the > built-in telnet, they can be used quite easily (so > can the NT4-level telnet > client, which you have a full right to use on Win2K > and XP if you are in some > sort of channel license program - e.g., you don't > buy XP/Win2K from system OEMs > or retail stores). > > > > ----- Original Message ----- > From: "Nathan Hill" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, 2002-04-23 21:23 > Subject: Re: Large Scale Implementation > > > > Thanks for the info Alex. > > > > I have already planned on recompiling TighVNC with > SSL > > for use on the Windows 2000 and XP machines. We > will > > be offering remote support for our users. We use > both > > profiles and policies in a domain that is > currently > > managed by both NT 4.0 Servers and Red Hat Linux > 7.0 > > servers. As far as the passwords for the local > > machines and per user, our logon scripts will > allow us > > to force the passwords through a registry merge as > the > > user logs in. This will give us an easy way of > > changing the password also. Actually, I can force > any > > registry settings for VNC in this manor. In > addition > > to this, I plan on routing all traffic running on > VNC > > ports (5800-5999) through a proxy on a linux > machine. > > By doing this, I can make the user trying to > connect > > to the remote machine authenticate against the > domain > > using their username and password. I will also be > > able to keep a centralized log of who connected > where, > > and when. I am going to set up the proxy to > release > > as soon as the connection is made in order to not > > hinder performance too much. I am also planning > on > > using using a port scanner such as Nessus or Nmap > > (linux based) that will write a database of all > > machine names, ip's, and port numbers. I plan on > > using this database, in conjunction with PHP, to > > create a dynamic website that we will actually be > able > > to click on the computer name and connect to the > > remote machine as a url. > > > > If anyone has any suggestions or more questions, > > please let me know. > > > > Thanks, > > Nathan Hill > > --- "Alex K. Angelopoulos" <[EMAIL PROTECTED]> > wrote: > > > Short story Nathan is - it will be a bleeding > mess > > > with VNC - but it is the very > > > best of the possible choices for your type of > > > situation. > > > > > > In terms of raw connectivity and reliability, > VNC is > > > absolutely superb when > > > configured correctly - particularly when using a > > > lightweight recent version such > > > as TightVNC. > > > > > > The issues are platform-specific maintenance > ones, > > > and some of the details about > > > how you do it should be strongly influenced by > your > > > plans for VNC. > > > > > > My experience base in entirely within the > Windows > > > realm. Here are some > > > questions that will help answer yours: > > > > > > (1) On the Windows systems, are your plans for > > > remote support or for remote > > > desktop access for everyone? Remote support is > > > simplest; per-user remote > > > support is inherently messy in that environment > due > > > to the need for a pre-login > > > general access password as well as per-user > > > passwords, which cannot be > > > automatically synchronized with Windows local or > > > network passwords unless you do > > > some work with the PAM VNC mod. > > > > > > (2) What flavors of Windows? > > > > > > (3) Do you do currently use profiles and/or > > > policies? Both can help > > > dramatically. > > > > > > > > > > > > Resources to look at first would include Richard > > > Harris' FastPush for VNC > > > http://www.darkage.co.uk > > > > > > and the ADM template created by Daniel Quinlan: > > > > > > > http://projects.chaosengine.net/winvnc/winvnc.ADM > > > > > > > > > I have some remote monitoring and assessment > tools I > > > am working on myself, but > > > they are still rudimentary and going through > initial > > > "peer review". > > > > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
