Remote Tools (Securing SMS Features)

SMS 2003 includes the option to use Terminal Services, Remote Desktop Connection, and Remote Assistance, in addition to Remote Tools if the console and client operating systems support those options. For more information about their security and auditing, see the documentation for those operating system features.

Remote Desktop Connection and Remote Assistance are available in Windows XP and Windows 2003. You can control Windows 2000 Servers using Terminal Services in remote administration mode. If you have Advanced Clients running Windows 2000 Workstation, there is no remote administration capability built into the operating system, you can use SMS Remote Tools. Even though remote tools traffic is encrypted with standardized Microsoft cryptographic API’s; it should not be considered a secure solution.

Any software that allows viewing and control of remote systems represents a high risk to security and privacy. SMS Remote Tools also allow a non-administrator to execute programs in an administrative context, if they have sufficient permission to remote tools.

Use Remote Administration or Remote Assistance Instead of Remote Tools

It is strongly recommended that you use the Windows Remote Assistance and Remote Desktop Connection features of Windows XP and Windows Server 2003 rather than SMS Remote Control on computers running those platforms. Windows Remote Assistance and Remote Desktop Connection are more secure technologies and are built-in features of the operating system.

Use either Group Policy or SMS to configure Remote Assistance settings, but not both

You can use both SMS and Group Policy to make configuration changes to the Remote Assistance settings. When Group Policy is refreshed on the client, by default it optimizes the process by changing only the policies that have changed on the server. SMS changes the settings in the local security policy, which might not be overwritten unless the Group Policy update is forced. Setting policy in both places could lead to inconsistent results. Choose one of these methods to configure your Remote Assistance settings.

Important

The following best practices are included only to support Windows 2000 Professional clients because they do not include built-in remote management options. If your clients use Windows XP, Windows 2000 Server, or Windows Server 2003, use the remote management capabilities in the operating system instead because they do not have the vulnerabilities listed below.

These best practices would also apply to computers running Windows 98 and Windows NT 4.0, but they are not considered secure operating systems and are discussed in Appendix D: Appendix D: Legacy Client Security Environment.

Do Not Consider the “Ask For Permission” Setting to be Adequate Security for Remote Tools

When you enable the “Display a message to ask for permission option” as a site-wide setting, the user logged on to the client must grant permission for you to perform any Remote Tools function. However, if you perform a Remote Tools function (for example, Remote Control) on a client and then discontinue performing that function, you can perform the same Remote Tools operation to the same client for a period of up to 10 seconds without regaining the user’s permission. If you attempt to perform a different Remote Tools function, even within 10 seconds, the user must grant permission. After 10 seconds, an attempt to perform any Remote Tool function on the same client requires user permission.

You can control Remote Tool security settings on computers running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family operating systems by manipulating appropriate registry entries and stopping and restarting the SMS Remote Control Agent. Ensure that remote registry editing and remote service control are properly secured.

The best mitigation is to use Remote Assistance instead of Remote Tools. Permission Required is a security feature of Remote Assistance itself. SMS cannot modify the requirement for the user to authorize the Remote Assistance session.

Have a Plan to Recover a Failed Remote Tools Session

Network conditions could cause the Remote Tools session to fail. Users at the remote computer can also terminate the remote control session before the administrator is ready. If the session fails before you log out of the remote computer, the remote console remains logged on with your credentials, and potentially without any administrative supervision. Consequently, anyone who can get physical access to that computer has your security rights and permissions. This can represent a significant security risk.

When using Remote Execute, any process started by the remote application can continue running even when the remote application has been closed. This could allow the local user a way to access the administrator’s security context.

To recover from a failed Remote Tools session, restart the computer by using a remote restart tool, such as Shutdown.exe. If any trusted staff is available at the remote location, you can ask them to log you off the computer.

Do Not Rely on Collection Security to Control Remote Tools Access

Bypassing collection security for Remote Tools is easy for knowledgeable or determined people. They could set up an SMS site that is not part of your SMS hierarchy and create resource records for clients they want to control. They could grant themselves any rights they want on those resources. Alternately, they could use the Remote.exe /SMS:nosql switch, as described in the “Remote.exe” section later in this chapter. You should think of collection security for Remote Tools as an organizational convenience and effective for staff that follow your policies and procedures.

Limit the Permitted Viewers List

Local administrator rights are not required for a user to be able to use Remote Tools. If the collection and Permitted Viewers list security is met, the Remote Tools user can use Remote Tools on the client.

Specify required global groups

Members of global groups that are members of local groups listed in the Permitted Viewers list are not enumerated, and thus members of global groups are not granted access permissions when they are nested in local groups. To avoid confusion, explicitly specify all global groups on the Permitted Viewers list.

Specify the domain context for user accounts

The Permitted Viewers list is intentionally ambiguous because a user is authenticated against the list at the client, and the SMS site server might not have access to the same domains as the client. Consequently, you can enter an account name in the Permitted Viewers list without specifying a domain for the account. However, the list must be clear at the client. Therefore, it is recommended that you enter an account name in the Permitted Viewers list by using the domain\account format to remove any ambiguity that might occur at the client.

Remove localized versions of the Administrator user name

In SMS 2003, no names appear in the permitted viewers by default.

If you upgraded from SMS 2.0, the localized versions of the “Administrator” user name that appear by default in the Permitted Viewers list could give Remote Tools access to unintended users. If you do not use the localized versions of the “Administrator” user name in your organization, remove them from the Permitted Viewers list. Removing unnecessary accounts from the Permitted Viewers list also reduces the amount of time and the amount of network authentication traffic needed for the client to authenticate the user and establish the remote session.

Do Not Use Remote Execute to Run Administrative Tasks

When you run programs on client computers using SMS Remote Tools, the programs run in the security context of the administrator remotely initiating the programs and not in the context of the user who is logged on at the time. If the remote execute session terminates prematurely, it could leave the user with an open administrative application.

Do Not Enter Passwords for Privileged Accounts During Remote Control Sessions

The password is secure to the client computer, but the password is entered through the virtual keyboard. Software that observes keyboard input could capture the password. Or if the program being run on the client computer is not the program that the remote control user assumes, the program might be capturing the password. When accounts and passwords are required, the end user should enter them.