MSLOGON locking out user account, FYI

[garyamort]

I recently installed UltraVNC on a Windows2000 system and used the "Require MS Logon" option. The system is a stand alone Windows2000 server, not a domain controller or a member of a domain.

We found that if an incorrect password was entered for the userid, the local windows account would be locked out after 1 attempt to log on.

We also found that members of the local administrators group could log on regardless of whether or not they were in the VNCACCESS group.

I enabled the New MS Logon option(which we had ignored since we were not dealing with multiple domains).

With this feature enabled, an incorrect logon no longer locks out the windows account. Furthermore, now members of the local administrators group cannot log on unless they are also members of the VNCACCESS group.

As a complete aside, we have UltraVNC configured not to allow multiple connections. When someone attempts to log on if someone else is logged on the client dies and the user is not notified as to why they can't logon. As a workaround, if you create a file share for the UltraVNC directory and grant read access to your VNCACCESS group, they can check the mslogon.log file. The end of the file will note the last successfull logon, what the IP address and userid is. It will also note when the user disconnects. This information should be sufficient to contact the user and coordinate timing.

[Marscha]

MS-Logon II just makes 1 Windows logon attempt during a VNC logon.
MS-Logon I tries several Windows logons when checking if the user is allowed to open a VNC connection.
If Windows is configured to locked out a user after 3 failed attempts this will lead to a lock out after 1 failed VNC logon attempt.

MS-Logon II only authenticates users that are explicitely configured.
With MS-Logon I all members of the local administrator group are granted access.

But keep in mind that someone with local admin rights can always change the relevant registry settings to get VNC access.

The RFB-Protocol used by UltraVNC (version 3.3 with enhancements) does not send back the reason for a failed logon.
AFAIK version 3.8 informs the viewer about the reason for a denied logon.
But it would require a substantial change in UltraVNC's implementation to switch to 3.8.

[Guest]

MS-Logon II only authenticates users that are explicitely configured.
With MS-Logon I all members of the local administrator group are granted access.

But keep in mind that someone with local admin rights can always change the relevant registry settings to get VNC access.[/admin]

Considering the people accessing the system with VNC have admin rights to the system, they can change anything they want to and there is nothing I can do to stop them, all I can do is clean up the messes they make.

The RFB-Protocol used by UltraVNC (version 3.3 with enhancements) does not send back the reason for a failed logon.
AFAIK version 3.8 informs the viewer about the reason for a denied logon.
But it would require a substantial change in UltraVNC's implementation to switch to 3.8.

Even if this information was logged somewhere, that would be usefull.

For example, I share out the ULTRAVNC directory for read access to the people who are logging on. When VNC dies after accepting a logon, I just do a type of the mslogon.log file and I have a good guess on who is logged on based on who authenticated after the last disconnect. But it is tedious to do so.

obviously, mslogon.log isn't the right place for this info, but if VNC stuck it in the event log I'd work out a way to get that data out(the system is behind a firewall, you can't view the event log remotely). The event log merely contains the same information the mslogon.log file contains - ie bad logon request from IP address X, connection from user Y on IP address X, and disconnect from user Y at IP address X.

if in addition to the connection, the VNC logged an entry saying "connectiong refused because user Y is already logged on" or broke the logon event into "logon from..." and "connection from...established" that would help.

Yes, these folks are weird, they don't want to let anyone else connect if they are already connected because they are not willing to communicate within a team of 6 so as to avoid messing each other up.