Skip to content

Add support for secure reuse of Windows/domain credentials in UltraVNC Viewer when connecting to servers using MS-Logon / MS-Logon II #339

@exprotm

Description

@exprotm

In enterprise environments, admins often connect to many hosts per day. Re-entering domain credentials for every connection is slow and inconvenient. It would be very useful if Viewer could optionally use the current Windows logon session (SSPI / integrated authentication) or Windows Credential Manager instead of prompting every time.

Important: this should be implemented securely and should not require storing plain-text passwords in scripts, command-line arguments, or .vnc files.

This would make UltraVNC much more practical in Active Directory environments while preserving server-side authorization through AD groups and MS-Logon rules.

Detailed Review:

Please add support for a secure way to avoid entering domain username/password on every connection when using UltraVNC Viewer with MS-Logon / MS-Logon II authentication.
At the moment, UltraVNC works well with Windows/domain authentication on the server side, but the connection workflow is still inconvenient for environments where administrators connect frequently to many hosts.
Current behavior
When connecting to a VNC server configured for MS-Logon / MS-Logon II, the viewer prompts for Windows/domain credentials each time.
Even if the username can be prefilled, the password still has to be entered repeatedly.

Problem
In enterprise/domain environments, administrators often connect to many systems during the day. Repeated manual credential entry causes:

slower support workflow
unnecessary friction for helpdesk / IT teams
increased chance of typing errors
poor user experience compared to other enterprise remote-access tools
Requested feature

Add an option for secure credential reuse in UltraVNC Viewer for MS-Logon / MS-Logon II, for example:

use the currently logged-in Windows user token / SSPI / Integrated Windows Authentication
optional single sign-on behavior when the viewer is launched by an already authenticated domain user
optional secure use of Windows Credential Manager
support for a command-line or profile option to enable this behavior
policy/setting to allow administrators to choose between:
always prompt
reuse current Windows credentials
use stored credentials from Windows Credential Manager
Important requirement

This should be implemented in a secure Windows-native way, not by storing plain-text passwords in .vnc files, scripts, or command-line arguments.

Suggested use cases
IT administrators connecting to many domain-joined workstations/servers
helpdesk teams using UltraVNC throughout the day
managed enterprise environments with Active Directory
internal trusted networks where operator identity is already controlled by Windows logon
Expected result

A domain-authenticated administrator should be able to launch UltraVNC Viewer and connect to approved hosts without retyping credentials every time, while still preserving server-side authorization via AD groups / MS-Logon rules.

Why this matters

This would significantly improve UltraVNC usability in enterprise environments and make MS-Logon / MS-Logon II much more practical for daily operational use.

Possible implementation ideas
SSPI / Negotiate / Kerberos / NTLM integration
“Use current Windows credentials” checkbox in Viewer
secure Windows credential storage integration
admin policy to disable or require interactive prompt when needed
per-connection profile setting for credential behavior
Additional notes

This request is specifically about Windows/domain authentication workflows, not classic VNC password authentication.

The goal is to reduce repetitive credential prompts while keeping authentication secure and centrally managed.

I am using now helpdesk website and i am able to call presaved password from DB, but i want to do it enterprice way ;)

Image

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions