NTLM in Win32 VNC
Greg Hewgill
gregh "at" lightspeed.net
Tue, 23 Jun 1998 08:50:24 +0000
I have started to add NTLM authentication to the Win32 VNC client and
server. If you run the VNC server on Windows NT, and connect with a Win32
client (either NT or 95), your credentials will be authorized through SSPI
(Security Support Provider Interface) instead of a simple
challenge-response password. That is, your logon credentials for your
workstation will be (securely) passed to the server, so the server can find
out what your network logon name is.
All it does right now is verify your credentials, but doesn't apply any
access control. Next I'm going to allow you to configure the server to
accept connections only from a specific list of accounts. So if I'm logged
on as DOMAIN\Greg on any workstation, I would be able to connect to any VNC
server that allowed connections from my account without having to enter
another password.
A few questions for the ORL folks, or anybody else:
1. Since this isn't applicable outside the Windows world, is this something
you'd consider adding to VNC?
2. I added another authentication type in rfbproto.h, rfbNtlmAuth (=3).
This is easy to handle in the client, just add another case in
ClientConnection::Authenticate. In the server, however, there are only two
modes: "no password" and "require password". I suppose one approach would
be to allow the admin to select which authentication scheme was required in
the server configuration dialog box.
3. There appears to be no support for trying more than one authentication
scheme. It might be nice to be able to allow password-only access to a
server even if NTLM is enabled. This would allow you to connect with a
non-Win32 client if you had to.
4. When configuring the list of accounts which have access to the server,
there's the easy way and the hard way. The easy way would be to have a text
file (or equivalent) containing the names of the accounts that have access.
An incoming connection would be accepted if the client's account name
appears in the access list. The hard way is to create a dialog box
interface that allows you to add not only individual accounts, but local
and global NT groups too (ie. edit an ACL). Access would be verified
through AccessCheck() or equivalent. Anybody feel like writing the "hard
way"? :)
Greg Hewgill