Telnet and User Account Control

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

User Account Control (UAC) improves the security of a computer running Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008 by requiring that administrators run as standard users. Whenever you attempt a task that requires administrative rights, UAC prompts you for permission to continue. Only then is access granted to use the administrative abilities of your user account. This ensures that malware cannot run under your security context without explicit approval to compromise the computer.

UAC removes the Administrators group security identifier (SID) from your security token. Your administrative account runs by using this "filtered" token until you grant permission for its use, at which point you have a "full" token. Processes that you start normally use your "filtered" security token, and you are effectively a standard user. When you start a program by using the Run as administrator option, or software programmatically requests administrator rights, the UAC dialog box appears asking your permission. If you click Continue, then the program is granted access to your "full" token.

For more information about UAC, see "User Account Control" (https://go.microsoft.com/fwlink/?LinkId=68249).

Telnet, as a command-line-only program, cannot dynamically change your security context by using UAC when you open Telnet the way a graphical application can. Your Telnet session is either administrator-enabled or restricted to a standard user security context depending on how you log on to the Telnet server.

When UAC is disabled

If you choose to disable UAC on your Telnet server, then tokens are never filtered, and any user attaching to the server through the Telnet protocol will get all rights and permissions of the user account.

When connecting to the Telnet server by using NTLM authentication

When you connect to a Telnet server by using NTLM authentication, the token is filtered or not based on the following contexts:

• If you connect to a Telnet Server from a Telnet Client running on the same computer, then the Telnet session starts with the same token you are currently using. If you start Telnet by using the Run as administrator option, then you have a full token and you can run administrative tasks in the Telnet session. If you do not start Telnet by using the Run as administrator option, then the Telnet session uses a filtered token, and you cannot perform tasks that require administrative rights.

• If you connect to a remote Telnet server over the network, then the Telnet server uses a full token that allows you to run administrative tasks in the Telnet session.

When connecting to the Telnet server by using password authentication

When you connect to a Telnet server by using password authentication, the token is filtered or not based on the following three conditions:

• The security privilege of the Telnet Server service, either NetworkService or LocalSystem.

• The value of the LocalAccountTokenFilterPolicy registry key, either 0 or 1.

• Whether the user account is a domain account or an account local to the Telnet server.

The default password is password.

The following table shows the results of the possible combinations of these conditions when using password authentication to connect to a remote Telnet server. A dash in a cell indicates that setting does not exist.

For more information about how to configure the service privilege and the LocalAccountTokenFilterPolicy registry key, see Configure Telnet Server to Allow Administrator Access with Password Authentication (https://go.microsoft.com/fwlink/?LinkId=106279) in the Telnet Operations Guide (https://go.microsoft.com/fwlink/?LinkId=106284).

See Also

Concepts

Controlling Access to a Telnet Server
Telnet Server Authentication