UltraVNC and MS-Logon Windows Authentication

Currently there are three different authentication methods available for UltraVNC Server Connections:

Classic VNC Authentication
MS-Logon I
MS-Logon II

Classic VNC authentication stores a password on the remote machine. When connecting with the viewer, this password has to be entered (just like traditional VNC applications):

Both MS-Logon methods rely on Microsoft Windows Logon authentication, i. e. username and password of a Windows domain or machine account is used for authentication:

MS-Logon I restricts the user accounts to be in the same domain than the machine account, but is available on Windows 9x.
MS-Logon II allows for cross-domain authentication, but only works on Windows NT4, Windows Server 2000, Windows XP and Windows Server 2003.

Classic VNC Authentication

Documentation to be Completed and edited further:

Password can contain only 8 characters, anything more than this is ignored (8 Bit password is a limitation of the original VNC system, and is maintained for compatibility with other VNC systems)
Password is stored in an encrypted format in the ultravnc.INI file

MS-Logon I

With UltraVNC, the WinVNC Server access can be managed using MS Users, Domains and Groups available from the machine that is hosting this WinVNC server. Currently, NT4 domains and active directories are supported. Child domains are NOT supported, user has to belong to the server's domain.

Right click the WinVNC icon in the System Tray and choose "Admin Properties":

In the Admin Properties page check "Require MS-Logon".

Then click on "Configure MS Logon Groups".
Here you can add or remove users and groups or change their rights:

A few things must be known and configured if you want this functionality to work fine on your WinVNC Server machine, and it depends on the version of Windows that is used.

To use MS Logon under Windows 95, Windows 98, and Windows Millennium Edition, you also have to enable the NTLM security services by opening Control Panel, Network, Access Control, and then selecting User-level access control. Windows 9.x require 2 dlls radmin32.dll and rlocal32.dll this can be found in the nexus.exe.

Under Windows XP, the ForceGuest registry value is set to 1 by default in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

On a Windows XP computer you must check:

If the Guest account is enabled, an SSPI logon will succeed as Guest for any user credentials.
If ForceGuest is disabled (set to 0), SSPI will log on as the specified user.
If the authtest util gives guest account blocked, an open guest account is detected and ms logon denies all access.

MS-Logon II

Description

In addition to the first implementation of MS-Logon (MS-Logon I), MS-Logon II is able to do cross-domain authentication, i.e. the user account can be in another domain than the computer account.

Supports

Windows NT4, Windows Server 2000, Windows XP and Windows Server 2003.
Any possible nesting of groups and users.
Different naming styles:
- domain\user
- This email address is being protected from spambots. You need JavaScript enabled to view it. (UPN, i.e. User Principal Name)

Requirements

On Windows NT4, you need at least SP4 and the security configuration manager installed.
Under Windows XP, the ForceGuest registry value is set to 1 by default in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
If the Guest account is enabled, an SSPI logon will succeed as Guest for any user credentials.
If ForceGuest is disabled (set to 0), SSPI will log on as the specified user.
So it's important to disable ForceGuest. Otherwise all authorization is done against the guest account!
Policy Settings: Authentication will fail if "Deny logon to the computer from the network" is enabled for a group the logon account is a member of. This applies to both Local Policy Settings as well as Group Policy Objects.
So make sure user accounts used for MS Logon authentication are not affected by these settings.

Configuration

Manual configuration

Right click the WinVNC icon in the System Tray and choose "Admin Properties":

In the Admin Properties page check "Require MS-Logon" and "New MS-Logon":

Then click on "Configure MS Logon Groups".
Here you can add or remove users and groups or change their rights:

Interact is the normal mode where you can take over mouse and keyboard. It's a synonym for Full Control.

View only allows the account to view the remote screen, but local mouse and keyboard cannot control the remote screen.

Automated configuration

You can use the MSLogonACL tool to export the ACL from one machine and import it to another.

To be tested

Since MSLogon II is relatively new and there are various different scenarios how to use it, we encourage everybody to share their experience. Please post your results to the UltraVNC MS-Logon forum.
There are a number of factors which are to be considered: Different OS versions, if Active Directory is used or old-style NT trusts, whether local or domain based accounts are used, the naming convention which is used and various possible nesting of groups.

OS: Windows NT, Windows 2000, Windows XP, Windows 2003
Infrastructure: With/without Active Directory
Accounts: Local and/or domain users/groups
Naming styles: user, machine\user, domain\user, This email address is being protected from spambots. You need JavaScript enabled to view it. (UPN), group, domain\group
Domains: (implies trusts/AD) user and/or group in other domains than computer, nested groups over multiple domains

Known bugs (not fixed yet)

Error reporting / debugging to be improved

History

31. 01. 2005: Fix: Change in platform detection to call security.dll or secur32.dll.
Now no platform detection is done at all (seems to lead to problems on NT4SP6a), instead secur32.dll is called. If the call is not successful, security.dll is called.
10. 12. 2004: Fix: Certain passwords (e.g. Abc0DefG) lead to authentication failure.
(see https://forum.uvnc.com/viewtopic.php?t=803)
08. 12. 2004: Fix: Changed authSSP.dll to Unicode to allow for extended chars (ä, ö, ü, ç, ß etc.) in passwords.
(see https://forum.uvnc.com/viewtopic.php?t=1259)
29. 10. 2004: Fix: Usernames with spaces fail to load with MSLogonACL tool.
(see https://forum.uvnc.com/viewtopic.php?t=1046&highlight=#4025)
07. 10. 2004: Changed list of groups to a real ACL.
Changed UI to Security page.
Added import/export tool for ACL.
20. 08. 2004: Fix: Change in platform detection to call security.dll instead of secur32.dll on Windows NT4.
04. 08. 2004: Authorization now uses Access check with Security descriptor and Access Token.
Only one Windows logon attempt is required to test authentication and authorization.
25. 06. 2004: First try.

MSLogonACL for UltraVNC

What is MSLogonACL?

The purpose of MSLogonACL is to allow for automated UltraVNC installations including access rights configuration for MS-Logon II.

With the new MS-Logon functionality in UltraVNC, the access rights are stored in an ACL (access control list). This is a binary structure which holds a list of SIDs (security identifiers) together with the description which rights are granted or denied to each SID.

The ACL can be edited via the VNC properties page. In order to allow for automated VNC installations a method is required for configuring the ACL from the command line. This is the purpose of MSLogonACL.

Exporting an ACL

MSLogonACL /e file for exporting to file .

If file is omitted, the security settings are printed to the console (stdout).
Lines beginning with == are debug information on stderr.

Importing an ACL

MSLogonACL /i /a file for appending ACEs to the current ACL or
MSLogonACL /i /o file for overwriting the current ACL
reading the security configuration from file .

Format of the configuration file

allow 0x3 domain\account
or
deny 0x3 domain\account

0x1 is View only, 0x3 is Interact and implies that you can also view the remote desktop.

domain can be a computer name or the name of a domain.
If domain is not specified (like deny 0x3 account), Windows tries to match the account name to a local or a domain account.
It is not recommended to omit the domain part since this may lead to unexpected results.

account can be group name or username.

If the account name contains spaces, the domain\account expression is to be enclosed in quotation marks:
allow 0x3 "domain\account"
Even if the account name doesn't contain spaces, quotation marks won't hurt.

MSLogonACL has two abbreviations for special domains:
one dot to denote the computer name and two dots to denote the computer's domain:
.\account for a local account on the computer
or
..\account for an account in the computer's domain.